TestDriven.NET vs. MS Team Suite

[Shawn B.]

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

[Shawn B.]

Nevermind all. It turns out that I had a problem with the solution file on
my workstation and getting it from source control from scratch solved my
problems. NCover/NCoverExplorer will monitor coverage for any project that
has a PDB file in the target build folder.
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