What should include in unit test code coverage?

Question

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

getters and setter methods
button click events.
public functions
private functions

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

Might be of interest: https://stackoverflow.com/a/90021/1336590 — Corak, Sep 26 '17 at 09:58
General advice is to test the public interface of your objects. — Bradley Uffner, Sep 26 '17 at 12:40

score 1 · Accepted Answer · answered Sep 26 '17 at 13:50

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.

Eric, thanks for your input it's really valuable, being said, it means I can exclude those part of code sections which not need to be tested from code coverage. right? I can exclude those getters and setters and maybe button click events through .runsettings file in mstest. is that will be fine? — SmartestVEGA, Sep 27 '17 at 05:02
Really, it's entirely up to you. Do you want the coverage metric to show that you have 90% coverage of 80% of your code (the other 20% being the UI code-behind, etc.)? Or would you rather have the metric show 72% coverage of all your code? — Eric Olsson, Sep 27 '17 at 12:53

What should include in unit test code coverage?

1 Answers1