I have an old WinForm application written in .NET 2.0. The application doesn't follow any pattern or layer pattern. My client now want to introduce unit testing Framework. As it is live application so it very risky to re-write the whole code again. What approach should i follow ?
Thanks in Advance
There's a book I've seen recommended often on this exact subject, I haven't read it but it seems appropriate for your problem, though I don't know if the fact that it's WinForms complicates this or not.
"Working Effectively with Legacy Code"
In WinForms it's really hard to unit test because the code behind is linked tightly to the GUI itself. Some automation tests will probably be the best you can get on a WinForms application without going out of your way to change the program.
If your client want a testable solution, I would suggest making it in WPF and use a MVVM framework like Caliburn.Micro that emphasizes unit testing.
Unfortunately, that means rewriting the entire application.
Short answer
Either rewrite application, or don't bother to much with the unit tests.
Since WinForms applications typically have a UI that is strongly coupled with the underlying "data model", some form of automated UI testing is probably your best bet - i.e. an external application emulates user's clicks and other interactions with the UI and checks whether your program is in expected state after that.
You may want to take a look at:
http://smartbear.com/products/qa-tools/automated-testing/supported-testing-types/functional-testing/
To do just the UI tests (since its a .net based) you could use .Net light weight Test automation feature. Details here http://msdn.microsoft.com/en-us/magazine/cc163864.aspx You dont have to use an external tool for automating it. But again, to test the underlying layers or business logic you have to extend the test cases.
I would recommend you move the most critical parts to normal C# classes and unit test those. And then only do UI testing on the complicated parts of the GUI. I have worked on a legacy project but with ASP.NET Webforms instead of Windows Forms and what I noticed is that some parts of the system changed often and were good candidates for refactoring and unit testing while other parts never ever changed and just were not worth the effort of testing.
If this is a large project then this could take a long time. A huge part of the work is making the code testable and introducing some sort of MVP (Model-View-Presenter) pattern to be able to separate the GUI code from the business logic.
I would highly recommend Working Effectively with Legacy Code as recommended by Eoin Carroll. It describes techniques to work with legacy code and also provides motivation (you could be in for some tough times) by showing that it can be done.
Also take a look at these two StackOverflow questions(here and here) for discussions on WinForms and MVP.
That depends on what you want to test, and how the app is written.
GUI is hard to test, but check out some of the other answers. If, as I suspect, you just want to test the business layer, that's easier:
If the app has the business and GUI decoupled, then you can easily use NUnit, either by integrating it into the project from your IDE, or in NUnit's own way, then write tests to cover what functionality the business layer exposes to the GUI.
If the app isn't decoupled, and you have a lot of the logic in the GUI, then you really need to refactor and decouple. Without doing this you will be restricted to testing via the GUI, which is difficult and not really full-proof, and it means trivial changes to the GUI may invalidate your testing of the business logic.
