Understanding of Code Coverage Analysis in C#

In my previous post i have explained about Unit testing in c#

Code Coverage is to determine to what portion of your project code is being tested by Unit testing, you can use the code coverage feature of Visual Studio.

Code coverage is an option when you run test methods using Test Explorer.

Analyze code coverage on unit tests in Test Explorer:

1.       On the Test menu, choose Analyze Code Coverage.

Code Coverage Results:

2.       To see which lines have been run, choose    Show Code Coverage Coloring IconShow Code Coverage Coloring.

Test Method:

Actual Method:

Discussion on Code Coverage %:

When any programmer starts writing the Unit testing, they will have one question in mind, how much we need to aim for code coverage percentage. So they will go and keep on asks to their Manager about Code coverage percentage.

Below is the discussion happened between Programmers and Manager about Code Coverage percentage.

Programmer 1: I am ready to write some unit tests. What code coverage should I aim for?

Manager: Don’t worry about coverage, just write some good tests.

Programmer 1: Smiled and left.

 -------------------------------------------------------------

Programmer 2: He also asked the same question (What code coverage should I aim for?) to Manager.

Manager: pointed at a pot of boiling water and said: “How many grains of rice should I put in that pot?”

Programmer 2: “How would I know? It depends on how many people you need to feed, how hungry they are, what other food you are serving, how much rice you have available, and so on.”

Manager: Exactly, you are correct. That will be the answer for you question.

Programmer 2: Smiled and left.

 ----------------------------------------------------------------

Programmer 3: He also came and asked the same question to the Manager about code coverage.

Manager: frustrated and Said 80 percent and no lees with some stern voice.

Programmer 3: Smiled and left.

 --------------------------------------------------------------------

These whole conversation observed one programmer (Programmer 4) and approached Manager

Programmer 4: Sir today I overheard you answer the same question about code coverage with three different answers. Why?”

Manager: Replied like below

Programmer 1 is new and getting started with Unit testing, so I want him to write unites cases first instead of concentrating on Code coverage.

Programmer 2 has quite experience at programming and testing. When I replied by asking him how many grains of rice I should put in a pot, I helped him to realize that the amount of testing necessary depends on a number of factors, and he knows those factors better than I do.

Programmer 3 always wants only simple answers – even when there are no simple answers … and then he does not follow them anyway

Conclusion: You should focus on writing good Unit test cases instead focus on the code coverage percentage.

Agile-Scrum: End -to-End Process

Agile-Scrum is a mostly widely accepted methodology of agile development. The term scrum is taken from the sport rugby in which the entire team works to get possession of the ball.

 

Scrum Framework:

Scrum Roles:

In the Scrum Business Owner, Stake holders and Scrum team will involve.

Scrum Team: Scrum team consists of the product owner, Scrum master and the development team. The Scrum team as a whole is responsible for delivering incremental versions of a shippable product at the end of each sprint. A definition of Done is agreed upon at the beginning of the sprint.

Product owner:  He is responsible for creating a prioritized wish list called a product backlog.

Scrum Master: He ensures that Scrum is understood and enacted in the project development. He is responsible to identify what kind of external interactions are required with the development team.

He also ensures that daily stand up meetings and other Scrum events are facilitated as required. In case any impediments are hampering the progress of the development team, he makes sure that they are resolved in a timely manner.

Development Team: Consists of professionals who do the work for delivering a potentially releasable increment of Done.

Scrum Artifacts:

Product Backlog: The product backlog is a complete list of the functionality that remains to be added to the product. The product backlog is prioritized by the product owner so that the team always works on the most valuable features first.

Sprint Backlog: During the sprint planning meeting, team members create the sprint backlog. The sprint backlog can be thought of as the team’s to-do list for the sprint. The sprint backlog is the list of stories and tasks the team needs to perform in order to deliver the functionality they committed to deliver during the sprint.

Burn down Charts: We have two types of burn down charts i.e .  Sprint and Product backlog burn down charts.

Ø   Sprint backlog burn down Chart: It is useful for predicting when all of the work will be completed. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference.

Ø    Product backlog burn down Chart: The release burn down chart that shows the amount of work left to complete the target commitment for a Product Release.

Scrum Ceremonies/Meetings:

A Team works on a sprint for anywhere between 1-4 weeks. An ideal sprint duration is 2 weeks.

Sprint Planning: What has to be done in a sprint is defined in the sprint planning. Product owner will decide and prioritize the back log items to pull in to the Sprint. Once planning is done Development team and QA team will create Dev and testing and etc. tasks for each item (PBI/Bug).

Here PBI (Product backlog item) is nothing but a feature and Bug is nothing but defect/issue.

Daily Scrum: This is the status meeting among team(s) members; in this meeting each team member gives a status on the following three criteria’s:

1.       What I did yesterday.
2.       What I will do today.
3.       Any Impediments?

Sprint Review: It is held at the end of the sprint. Development /QA team will give the Demo of the items which they worked on that Sprint. In this Business team, stake holders and product owners are the audience.

Sprint Retrospective: This gives an opportunity to the development team, QA team and Business Owner to discuss the following three things:

1.       What went well?
2.       What went wrong?
3.       What we want to improvise?

Backlog Grooming: In the Grooming session, team will get the clarifications on each of the back log items and estimate the stories using different tools like Planning poker and etc.

Release Planning: RM (Release Management team) and Business team will decides when we need to release the product with new features/Bug fixes. Ideally every 4-6 sprints will have the release.

Scrum activities:

• A product owner creates a prioritized wish list called a product backlog.
• During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
• The team has a certain amount of time, a sprint, to complete its work – usually two to four weeks – but meets each day to assess its progress (daily scrum).
• Along the way, the Scrum Master keeps the team focused on its goal.
• At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder.
• The sprint ends with a sprint review and retrospective.
• As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

Scrum Values:

Commitment – Be willing to commit to a goal. Scrum provides people all the authority they need to meet their commitments.

Focus- Do your job. Focus all your efforts and skills on doing the work you have committed to doing.

Openness – Scrum keeps everything about a project visible to everyone.

Respect- Individuals are shaped by their background and experiences. It is important to respect the different people who comprise a team.

Courage- Have the courage to commit, to act, to be open and to expect respect.

Unit testing in c#

In this post I am going to explain about uses of unit testing and writing unit test cases in c#.

Many junior/fresher developers will have confusion like who really deal with Unit testing. Unit test cases are written by developers.

What is Unit Testing?

It tests behavior of a function/method by writing another piece of code.

Why unit tests?

·         Normally Software Projects are intended to run for long term at least for a min. of 5 years.

·         During this period, maintaining the application is very crucial.

·         Any Change Request received might impact the other functionality of the application.

·         So, before deploying the change in Production lot of regression testing has to be done. This consumes lot of tester’s time.

Imagine a situation where the Change requests are happening very frequently, the effort required for regression testing will be very high and the possibility of having defects will also be high.

Software Maintenance with Normal approach (Regression Testing):

Regression testing is the process of testing changes to computer programs to make sure that the older programming still works with the new changes.

Software Maintenance with Unit testing:

·         Unit Tests will certainly help in minimizing the regression testing.

·         Every method will be associated with Test Methods. Test Methods will test the purpose of the actual method.

·         Test Methods will check for below scenarios

·         Positive / Success scenario

·         Negative / Failure scenario

·         Exception / Error Handling scenario

·         A normal method might require more than one Test Method depending on the complexity of the Method.

·         Before Code Delivery., Developer has to ensure that all the test methods (in entire solution) are getting passed.

Software maintenance with TDD (Test Driven Development):

TDD is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and then refactor the code to pass the test.

Writing Unit test cases:

We have below frameworks to write unit test cases in C#.

·    MS Test

·      NUnit

We have AAA pattern to write unit test cases:

Arrange all necessary preconditions and inputs.

Act on the object or method under test.

Assert that the expected results have occurred.

Following are the steps to create the unit test project:

Right click on the solution explorer and click on Add and select Unit Test Project

Solution Explorer:

Test Class:

 using System;

using Microsoft.VisualStudio.TestTools.UnitTesting;

using BusinessManager;

namespace UnitTestProject1

{

    [TestClass]

    public class UnitTest1

    {

        [TestMethod]

        public void GetNameTest()

        {

            //Arrange

            Employee objEmployee = new Employee();

            String firstName = "Narasimha";

            String lastName = "Reddy";

            String expected = "Narasimha Reddy";

            String actual;

            //Act

            actual = objEmployee.GetName(firstName, lastName);

            //Assert

            Assert.AreEqual(expected, actual);

        }

    }

}

Employee Class:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace BusinessManager

{

    public class Employee

    {

        public string GetName(string firstName, string lastName)

        {

            return string.Concat(firstName," ", lastName);

        }

    }

}

I hope you it will help you to get idea on unit testing.

Happy Coding......