I have taken on a project that has been underway for months. I've yet to ever do unit tests and figured it would be a decent time to start. However, normally unit tests are written as you go and you plan for them when beginning the project. Is it reasonable for me to start now? Are there any decent resources for setting up unit tests without starting a brand new solution (the project is already underway). Using vb.net with VS2005
Thanks in advance :)
Write tests for the code you are touching right now. When you have time (yeah, right) you can cover the other parts of the program.
Also, write test before you refactor; that way, you can make sure the old version does the same thing as the new one.
Adding unit tests to a large existing codebase is harder than beginning from scratch. I will encourage you to do so anyway since it will pay of in the long run.
I've done the same exercise and my take is: whenever you want to change an existing feature, create at least unit tests that verifies that the changed code works as expected. You should also strive to test other code that is directly dependent on the code your changing. That way you have some insurance that your change is not breaking a lot.
Of course, whenever you create new code, this should be completely backed by unit tests.
This way you will gradually build up a solid unit test base.
Unit test projects are just Library projects that you add to the solution.
Anytime is a good time to start unit testing, although it becomes harder as further into the project as you will find things have become tightly coupled without consideration for testability.
The best place to start would be on anything new you wish to develop or on critical sections which currently have lots of issues. If you find you have spare time, try refactoring your code and adding tests to it.
You should use a separate project within the solution for your unit tests so you don't have to distribute it with your application.
As long as you can cover a particular area completely, then it's worthwhile.
If you can't, then unit tests begin to loose their value, as they give a false impression that a particular area has been tested correctly.
I would still say they are beneficial if written correctly. However you do need to be aware that they will slow down development initially and ideally need to be kept up to date by other members of your team, who are working on the same area of code.
What I would do going forward is to:
That would get you a fair way to getting some test coverage without resorting to switching your whole team to just writing tests for a sprint or two.
Hi
I would say that the functions ought to be unit tested needs to be small so that not too much state change happens in them. In fact if you write unit tests before development then you will always design your functions to be modular.
Please have a look at http://msdn.microsoft.com/en-us/library/ms364064.aspx
cheers
Starting this late on writing unit tests just means that you will have a lot more to write right now. It's worth it IMO to take the time though, but unfortunately, sometimes time/budget doesn't allow for it.
The basic issue you face is something Michael Feathers refers to in Working Effectively with Legacy Code as the Legacy Code Dilemma, a.k.a. the Refactoring Dilemma:
As a way out of the dilemma, the book describes a set of dependency-breaking techniques. These are relatively safe ways to pry apart dependencies in order to isolate code and get it under unit test. The book's examples are in Java, C++, C, and C#. I don't know enough about vb.net to say how many of the techniques would apply.
There is also some general discussion/encouragement here on the c2 wiki.