Greatings,
I started using the Team Developer version of Unit Testing and the Team
Developer version of Code Coverage. One thing I really like about it is
that I can create my Unit Tests in a seperate project in the solution and
when I view code coverage, the IDE will show me the coverage statistics for
any project in the solution that was tested.
Since I pay for my own personal Team Suite subscription out of my pocket, I
can only use the MS integrated Code Coverage tools from home. At work, we
only have VS 2005 Professional.
So started tinkering with TestDriven.NET. When I create a seperate project
that will act as the unit testing harness in the solution, and run with Code
Coverage, I only get to see the code coverage for the assembly that actually
contains the unit tests; in this case, I can see that 100% of my Unit Test
code was covered, but not the answer I'm looking for. Because not everyone
at work has TestDriven.NET or NUnit installed and we may not continue using
it anyway because it is not easy to get the company to license 3rd party
software, no matter how useful (and no we are not in the stone age, just
been burned too many times), it is not feasible for me to be checking in
projects that have references that no one else has -- which will prevent
builds from being released until the invalid references are (most likely)
removed.
My question here is, if any knows the answer, does NCoverExplorer/NCover
provide a way for me to know how much of the target project was covered
during a Unit Test or does it only profile any project that contains the
Unit Test itself? I would see this as a major disadvantage compared to the
Microsoft offerings, because I must be able to maintain a seperate project
containing the Unit Tests in order to introduce this into my work place
(more than 1 million lines of code and 70 projects in the various dependancy
chains). Further, I'm not about to mix my Unit Test code with the project
itself.
This may not be the right place to post, but I figured that there must be
enough people here that practice TDD to make it worth my while.
Thanks,
Shawn
I started using the Team Developer version of Unit Testing and the Team
Developer version of Code Coverage. One thing I really like about it is
that I can create my Unit Tests in a seperate project in the solution and
when I view code coverage, the IDE will show me the coverage statistics for
any project in the solution that was tested.
Since I pay for my own personal Team Suite subscription out of my pocket, I
can only use the MS integrated Code Coverage tools from home. At work, we
only have VS 2005 Professional.
So started tinkering with TestDriven.NET. When I create a seperate project
that will act as the unit testing harness in the solution, and run with Code
Coverage, I only get to see the code coverage for the assembly that actually
contains the unit tests; in this case, I can see that 100% of my Unit Test
code was covered, but not the answer I'm looking for. Because not everyone
at work has TestDriven.NET or NUnit installed and we may not continue using
it anyway because it is not easy to get the company to license 3rd party
software, no matter how useful (and no we are not in the stone age, just
been burned too many times), it is not feasible for me to be checking in
projects that have references that no one else has -- which will prevent
builds from being released until the invalid references are (most likely)
removed.
My question here is, if any knows the answer, does NCoverExplorer/NCover
provide a way for me to know how much of the target project was covered
during a Unit Test or does it only profile any project that contains the
Unit Test itself? I would see this as a major disadvantage compared to the
Microsoft offerings, because I must be able to maintain a seperate project
containing the Unit Tests in order to introduce this into my work place
(more than 1 million lines of code and 70 projects in the various dependancy
chains). Further, I'm not about to mix my Unit Test code with the project
itself.
This may not be the right place to post, but I figured that there must be
enough people here that practice TDD to make it worth my while.
Thanks,
Shawn
Comment