One thing I like about Visual Studio is the kind of features it offers in the Integrated Development Environment (IDE). Since I started working on Agile projects Code Coverage is one of my most favourite feature in VS 2008. Please refer to this article if you want to know how to enable code coverage feature in Visual Studio. Code Coverage and unit tests go hand in hand. Code coverage results are helpful in analysing how much code was covered as part of running a set of unit tests.
I prefer to keep my unit tests in a separate project within the solution. In the initial days of unit testing people would write unit tests alongside production code. The execution of unit tests was controlled through a pre-processor directive like #if UNIT (UNIT will be a configuration type just like DEBUG or RELEASE) using conditional compilation. If you build the project or solution in UNIT configuration it would execute unit tests or else the production code would have got compiled.
The problem with this approach is that its difficult to maintain tests in such a scenario. For the same reason I separate out the production code and the unit testing code. While working on a legacy application written in DOTNET Framework 1.1 I came cross a problem. There were many classes which were defined as Internal. These classes could have been unit tested easily had I followed the old approach of #if UNIT. But since because I was using separate project, I could not access these classes outside the assembly as a result of the protection level. One approach which I found very helpful was to use the InternalsVisibleTo attribute at the assembly level and make the Internal members visible to unit test assembly. Refere to this article to see how this works.
The other tip I would like to share is when running code coverage, there are pieces of code which is not covered. This results in the decrease in the percentage of coverage. Ideally I would want 100% of the code I have written to be covered. But system generated code like the AssemblyInfo.cs, Proprties.cs files or some code which does not contain any logic e.g. a DTO or an entity object with just get set properties are set of lines of code which I would want to ignore while running code coverage.
Once again Visual Studio comes to the rescue. There are two alternatives. You can use one of the following two attributes
1. [System.Diagnostics.DebuggerNonUserCode()]
2. [System.Diagnostics.DebuggerHidden()]
either at the class level or at a more granular level of methods, property etc.
Refer to this article for more details. One word of caution is that after setting these attributes, you'll not be able debug the piece of code.
In Agile they say you should try to cover around 80% of your code. Using these techniques I would suggest you should aim for 100% code coverage which we achieved in one of our projects.
I hope this is of some use. Until next post happy programming :)
I prefer to keep my unit tests in a separate project within the solution. In the initial days of unit testing people would write unit tests alongside production code. The execution of unit tests was controlled through a pre-processor directive like #if UNIT (UNIT will be a configuration type just like DEBUG or RELEASE) using conditional compilation. If you build the project or solution in UNIT configuration it would execute unit tests or else the production code would have got compiled.
The problem with this approach is that its difficult to maintain tests in such a scenario. For the same reason I separate out the production code and the unit testing code. While working on a legacy application written in DOTNET Framework 1.1 I came cross a problem. There were many classes which were defined as Internal. These classes could have been unit tested easily had I followed the old approach of #if UNIT. But since because I was using separate project, I could not access these classes outside the assembly as a result of the protection level. One approach which I found very helpful was to use the InternalsVisibleTo attribute at the assembly level and make the Internal members visible to unit test assembly. Refere to this article to see how this works.
The other tip I would like to share is when running code coverage, there are pieces of code which is not covered. This results in the decrease in the percentage of coverage. Ideally I would want 100% of the code I have written to be covered. But system generated code like the AssemblyInfo.cs, Proprties.cs files or some code which does not contain any logic e.g. a DTO or an entity object with just get set properties are set of lines of code which I would want to ignore while running code coverage.
Once again Visual Studio comes to the rescue. There are two alternatives. You can use one of the following two attributes
1. [System.Diagnostics.DebuggerNonUserCode()]
2. [System.Diagnostics.DebuggerHidden()]
either at the class level or at a more granular level of methods, property etc.
Refer to this article for more details. One word of caution is that after setting these attributes, you'll not be able debug the piece of code.
In Agile they say you should try to cover around 80% of your code. Using these techniques I would suggest you should aim for 100% code coverage which we achieved in one of our projects.
I hope this is of some use. Until next post happy programming :)
