Menu
I need to add unit tests for an existing solution with a lot of projects. Building the project takes a long time, so I decided to create another seperate solution for unit test projects. I don't know what's better: reference to dll or include in unit test solutions existing projects that I want to test.
How should I organize my test cases, and why? Please base answers on your own direct experiences.
561
There is no concrete rule for the size of a unit test obviously, but there are some heuristics people use when writing unit tests. A couple of them are that a unit test shouldn't exceed a dozen or so lines and a unit test shouldn't take more than a minute to write. Unit tests are supposed to be as short as possible.
The AAA (Arrange-Act-Assert) pattern has become almost a standard across the industry. It suggests that you should divide your test method into three sections: arrange, act and assert.
I strongly suggest that you include the project you want to test in the solution and reference that project.
In one big project I referenced only the DLLs and had a lot of problems with the unit tests testing old versions of the DLLs, because building the unit test project didn't automatically trigger a build of the project it tests.
96
Serghei, as Daniel Hilgarth points out it is advisable to include the unit test projects in your main solution. In addition, it is advisable to have a 1:1 relationship between your development projects and unit test projects.
That being said, something important to note is the number of projects in a solution increases the build time in a non-linear way.
One project I have worked on recently had 97 projects in a solution! The build time was over 10 minutes. By consolidating the code into fewer projects the build time was reduced to 2 minutes for the same LOC.
Developer productivity lost at the expense of 'correctness' can be very expensive in the long run. It is not just the build time lost, but also the time lost due to a break in concentration, annoyance on behalf of the developer etc... How many times have you personally been stalled by a slow build / computer / IDE and ended up browsing the web, losing 10 minutes before you realise "Oh, the builds finished!". I've been in a situation like this so bad that the time spent between builds was spent surfing job websites ;-)
As a workaround in large solutions I've done this.
This introduces the possibility your unit tests won't build as your development code diverges from the code the unit tests expect, however its a balance. A trade off has to be made to ensure the highest productivity, whether through pure development or time fixing broken tests, at all times. Productivity can be eroded not only through slow build and IDE but also by fixing those broken tests, so you have to ensure you don't swing too far when balancing this.
A final point to make is this. Have you considered setting up a console batch file to perform the team city build on local dev PCs? This can be performed as a last step before check-in to ensure developers are checking in code that builds and passes according to the TC setup.
Best regards,
24
As Daniel said, referencing the projects would be my preferred approach.
If you're wanting to improve the time it takes to do a local build consider using the Solution Load Manager extension to control which projects are loaded and which aren't. It can really help improve build times when you're only working on a subset of a very large solution.
20
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
