views:

83

answers:

3

I want to improve the roundtrip time when doing TDD. I guess the total compile time for the solution will be longer, but that is not important.

Background: When I watch the output window during compiling when I wait for my unittest to run, I see that some time is spent only verifying that depended projects does not need to be build.

Statement: Splitting the Testproject (today about 20k lines and dependency to nine other projects) into smaller test projects where each testproject tests a smaller part of the code, will give me less dependencies and therefore increase compile time for the testproject I'm currently working with.

Views?

+4  A: 

Typically, I'd suggest creating one test project per assembly, so it will have one dependency on the assembly under test. If the assembly to test is named MyCompany.MyProduct.Common, the test project would be MyCompany.MyProduct.Common.Test.

Also, you could use Continuous Integration to have the build server perform all the appropriate unit tests after a successful compile.

Wim Hollebrandse
Yes, one test assembly per actual assembly is the way to go.
Paolo
What do you do with common test code? Make a dedicated project like MyCompany.MyProduct.TestBase ?
Nasit
A: 

I would go down the route of splitting it into smaller projects making sure that the dependencies also drop. Circular references are the most important thing to watch out for.

The compile time may get longer but that can always be solved by investing in faster Hard drives, quicker CPUs and more RAM. Also by splitting it out you can speed up your build time if you have it running on a CI server because you can create run parallel tasks for each of the projects so instead of running synchronously, like VS would do normally, you can build each of them asynchronously and run then asynchronously.

AutomatedTester
+1  A: 

Call me crazy (I'm used to it!).

I put my tests in the same assembly as the code under test.

Code in namespace N.M gets tests in namespace N.M.Tests.

In this way, internal types can easily be unit tested, which is appropriate for TDD.

Without the complexity of additional assembly dependencies due to unit tests, you avoid the original problem.

The main objection I hear to this is that you don't want to ship your tests to customers. However, unless bandwidth or storage are particularly constrained, I haven't seen a real reason that shipping tests is detrimental.

Jay Bazuzi
Bad idea and goes against the general advice for unit testing.
Finglas
@Dockers: Could you be more specific? Why do you think it's a bad idea? What general advice for unit testing do you think it goes against? Is that advice unit testing advice, or TDD advice?
Jay Bazuzi
Not a bad idea actually, and cudos for you doing it even though you know alot things it's a bad idea.
Nasit
Besides the issue of shipping your tests (which is not necessarily an issue) I can't think of a reason that makes it "bad". That being said, you can test internals with a separate assembly too - you just need to use "Internals Visible To" and make it visible to your test suite.
Mathias