What is the accepted practice for adding Nunit tests to an existing solution?

Question

I have inherited a reasonable sized ASP.net solution that has no automated tests. The solution seems to include all of the source/pages in one solution with no name-spacing and no separation of tiers, so there are direct SQL calls within code behind files etc.

Before making changes to this site I would like to add some unit tests, preferably using nunit as I am familiar with the Xunit model, to give me some confidence that I have not broken anything. I do not have much .net experience, and particularly I am not sure about when to use projects vs solutions etc, although I am comfortable with the basic syntax etc of C#.

What is the recommended method of adding units tests to a solution? Should I create a separate Solution/Project for the tests and then add references to appropriate elements of the existing solution, or should I create a separate project within the existing solution to house the test suite.

I am really looking for the pros and cons of both approaches, or indeed another method altogether. What are peoples experiences of the best way to achieve this.

Answer 1

I'm not sure you can start with Unit tests. Remembering that the first rule is "Don't break what works", I would suggest starting with some integration or regression tests using something like WatiN or Selenium. Both of these frameworks can run the integration tests from unit test frameworks such as NUnit. Telerik do one as well but it's not free and I haven't used it.

Once you have that in place, you can start the process of moving code into layers with the knowledge that you're not breaking the website. This is then a good time to introduce unit tests.

This I would do by having one project that houses all of the unit tests, with references to the projects that contain the classes you are testing. I believe it's also good practice to separate your tiers into projects.

Answer 2

I prefer a new project in the same solution.

Pros:

1. Your tests always compile at the same time as the code under test.
2. Your test code is in a separate assembly so you are always testing the public interface.
3. Since your tests are not in the same project as code under test you do not have to deploy your tests with your application.

Cons:

1. You create a parallel namespace heirarchy that you should maintain if you move code under test around. Tools like resharper make this easier.
2. Visual studio is a little slower when there are a lot of projects. Not an issue for a smaller number of projects.

Answer 3

I'd place the tests in a different Project in the same Solution, so they won't be distributed along with the production versions.

Look into Working effectively with legacy code by Michael Feathers, he has a ton of tips on introducing unit tests in untested code.

There are refactorings that make unit tests easier and that don't change the program logic (e.g. the ones built-in in Visual Studio), you can use those in the initial stages to improve your program structure.

Don't be afraid to make your code "worse" in the initial stages to enable unit testing (like making methods or fields public that should be private or making everything virtual), as long as you make the code better when your tests are in place.

This includes temporarily adding tests in the production code itself: the first business is testing the code, you can move the tests later.

Answer 4

I would also recommend reading Working Effectively with Legacy Code by Michael Feathers.

As for the Solution structure while working with a Legacy code, I usually make a copy of the existing solution file, called it <>Test.Sln, and add a new UnitTests Project to the newly created solution file.

I add another test project for the Integration tests, as I like to keep the unit tests separate from the integration tests.