Is there a good measure of completeness of Unit tests

I have a class that I need to Unit Test.

For background I'm developing in c# and using NUnit, but my question is more theoretical:

I don't know if I've written enough test methods and if I checked all the scenarios. Is there a known working method/best practices/collection of rules for that?

Something like

• "check every method in your class ...bla bla "
• "check all the inserts to DB ...bla bla "

(this is a silly exampl开发者_如何学编程e of possible rules but if I had something not silly on my mind I wouldn't ask this question)

There are several available metrics for unit testing. Have a look into both code coverage and orthogonal testing.

However, I would say that this is not the best way of addressing the problem. While 100% code coverage is an admirable goal it can become the sort of metric which obscures that actual quality of the tests.

Personally I think you would get better results from investigating test driven development - using this approach you know you have good coverage (both in terms of lines of code and in terms of functionality of your class) because you have been writing the tests to exercise your class before you wrote the class methods themselves.

You might want to look at your test coverage. NCover is the code coverage solution from the developers of NUnit.

You can look into NCover or Visual Studio code coverage tool that support Nunit

The unit of measure for measuring test coverage in codes is called "Code Coverage".

As per Wikipedia:

Code coverage is a measure used in software testing. It describes the degree to which the source code of a program has been tested. It is a form of testing that inspects the code directly and is therefore a form of white box testing. In time, the use of code coverage has been extended to the field of digital hardware, the contemporary design methodology of which relies on hardware description languages (HDLs)

Code Coverage measurements are given in percentage. Different teams and projects sets their own test coverage goal. I don't know if there is an industry "best practice" number, but most of my project sets this number at 80%.

For instance, if you are working on a project that has a lot of UI code, chances are the unit test coverage for that is low, but if you're working on a library, chances are every method has a proper unit test.

For .NET, one of the popular tool for code coverage is NCover.

As the others have mentioned Coverage provides one metric by which to measure the quality of your tests, but this does not tell you anything about how well the tests test your code. Just because a line is executed, it does not mean that all possible permutations of that line have been executed.

you may find some usefulness for a tool such as pex, which will test your code with various inputs to see what is does in those situations. this will give you good covereage (as it will tailor the inputs to generate paths through all of the possible paths through your code) but will also give you good coverage of the possible inputs (like ensuring your methods are tested with null inputs, or that methods which take lists are tested with empty lists or lists that contain null items etc)

There are other intriguing initiatives like a tool which removes lines of code, recompiles, and re runs tests. If no tests fail in this scenario, then it assumes that you have a missing test, as there should be something which depends on that line, or else why is it there? I'll look for a link to that.