From what I ve seen and done, the standard practice for writing NUnit tests for a project is to create a separate project to contain the tests. So for exampleMessage 1 of 42 , Jan 24, 2008View SourceFrom what I've seen and done, the standard practice for writing NUnit
tests for a project is to create a separate project to contain the
tests. So for example if I have a project "MegaApp.DomainModel", I
would create a corresponding project "MegaApp.DomainModel.Tests" that
would have all the tests for that project. Recently I've been thinking
about putting the tests directly into the "MegaApp.DomainModel"
project in such a way that "Widget.cs" and "WidgetUnitTests.cs" would
be right next to each other in the Solution Explorer.
There are a couple advantages to this approach:
* The nearness of the files will make it easier (and therefore more
likely) that developers will work on the test in tandem with the class
under test (CUT).
* One can make private methods on the CUT into internal methods and
then write tests for them, if need be.
* Will effectively halve the number of projects in the solution (My
current solution has 40+ non test projects), making the solution
explorer a little less unwieldy.
* I'm thinking this will make it easier for devs unfamiliar with NUnit
testing to gain experience with it faster. (I'm currently trying to
introduce the concept to 10+ developers.)
And the only disadvantage I have thought of so far:
* The production assemblies have a reference to NUnit and contain more
types. Slower compilation and load time?
Thinking about it, that disadvantage really isn't that big of a deal
to me. So far I haven't thought of any other disadvantages. I'm
looking for any more advantages/disadvantages for this approach vs the
Hey Casey, ... Depends, I would say it s important if you do (or plan to do) Continuous Integration. I want CC.NET to perform developer builds (i.e. soon afterMessage 42 of 42 , Jan 24, 2008View SourceHey Casey,
> You don;t have to have one test project per project under test, in fact aDepends, I would say it's important if you do (or plan to do)
> few test projects is probably plenty for a few dozen projects. Test projects
> don't have interdependencies (or shouldn;t) so there is no need to split
> them for purposes of assembly deployment or fucntinal seperation,
I want CC.NET to perform developer builds (i.e. soon after an svn
commit) if any production or test code changes, and the easiest way
for that to happen is if the test project & code sit underneath the
project it's testing.
e.g. CC.NET monitors "svn://host/repo/trunk/src/Foo" for changes,
where Foo contains:
That way, any changes trigger a CI build.
Handy when ½ your development team is on the other side of the world
and you have CC.NET email the committer shortly after they break/fix
the build :)
> and the fewer test projects you have, the fewer I have to right clickWith TestDriven.NET you can run all test projects for a solution with
> and run each time I build in the IDE.
one right click from VS.
It's a wild world that we live in, you step to the vibe like a new
found religion, take your position, compile your vision, futurism,
algorithm has risen up! pfm - the western