CODEWITHSUNDEEP
c#asp.net.netunit-testingmstest
SmartestVEGA
SmartestVEGA

Reputation: 8909

What should include in unit test code coverage?

I am writing test methods for a class

Eg:

class employee{

   public int ButtonID
        {
            get
            {
                return 
                function(GetValue("ButtonID"), 0);
            }
            set
            {
                SetValue("ButtonID", value);
            }
        }

    public function getEmployeeID()
    {somthing; }

    private function setEmployeeID()
    {somthing; }

    protected button_click(e)
    { somthing; }

}

Here when we calculate code coverage it also includes

  1. getters and setter methods
  2. button click events.
  3. public functions
  4. private functions

Am I supposed to see the coverage of all above four?

Upvotes: -1

Views: 573

Answers (1)

Eric Olsson
Eric Olsson

Reputation: 4913

Specific to points 1 and 2:

Testing getters and setters depends upon what those accessor methods are doing. If they are auto-implemented, then I do not recommend explicitly testing them. I trust the .NET Framework's implementation. If you are looking for increased code coverage, then be sure you both get and set the property during other tests, and the coverage will be counted.

If there is something more complicated going on in the property accessors, then it may be useful to have unit tests to help create it (if following test-first TDD) or to ensure the logic is implemented correctly.

When it comes to UI-specific code, it is not worth trying to use unit testing to test it. Trying to manipulate a UI within a unit test leads to flaky, slow tests. If you want to test something within the button click handler, then try to extract that functionality into another class that can be more easily unit tested. Keep code-behind files as thin as possible--delegating work to other classes that you can test.

As to points 3 and 4:

As commenters have pointed out, public methods provide a rich target area for creating unit tests. You want to ensure that the public API of your class performs as you expect, and testing the public methods gives you the opportunity to see how easy it is to use the class being tested. If something is awkward to use in a test, it may be pointing to a need for a design change.

Only test your private methods through your public methods. Unit tests ought to test behavior of your class, not the implementation. Theoretically, you ought to be able to exercise your private methods through your public methods.

Upvotes: 1

Related Questions