The Art of Unit Testing: with Examples in .NET
Why do we need to have automated unit testing? How effective is it?
Automated unit testing is very valuable first and foremost because it is automatable (normally, we only consider it a 'unit test' when it is automatable). As the size of an application grows, manually testing the whole application may take hours or even weeks. Even testing just a small part of an application takes time and is error-prone. Unless you are autistic, you will not be able to focus on performing each manual test 100% correctly if you have to do it over and over dozens of times.
In Agile development, we operate with the concept of Rapid Feedback: the sooner you can get feedback about what you did was right or wrong, the more effective you can be. We all make mistakes, but it is a lot less expensive to discover and fix a mistake thirty seconds after it was made, than several days or weeks later. That is why automated testing is so important.
While you can do automated testing on many levels, unit testing is the most efficient type to implement. It may be the most difficult testing discipline to understand and master, but it is much more robust than any other type of testing.
If I want to start doing automated unit testing. Where should I start from? (have heard about nunit)
First of all, you need to learn some unit testing basics. Roy Osherove's book The Art of Unit Testing is a good introduction.
When it comes to frameworks, NUnit has been around for a long time, but it has some inherent issues.
If you already have Visual Studio Professional or Team System, there's a built-in unit testing framework commonly known as MSTest. Most people dislike this framework, but personally, I find it quite adequate. The IDE integration works well, but the API could be better.
If you are looking for a free, open source unit testing framework, I would recommend xUnit.net, which is a much more modern framework.
Do I need to keep anything in mind when designing my classes to facilitate automated unit testing?
Yes, each class should be able to be used in isolation. This can be very hard to do by up-front design, or if you are trying to retrofit unit tests onto existing code, but should come more or less naturally if you adopt Test-Driven Development (TDD).
Does C# have an in-built support for automated unit testing?
No, C# is just a language, but as I mentioned above, certain versions of Visual Studio has MSTest.
Can we also test GUI with automated unit testing or is it just business logic?
Unit testing GUI tends to be very brittle (that is, test maintainance is very high), so is generally not a good idea.
However, there are many design patterns that can help you extract all GUI logic into testable classes: Modev-View-Controller, Model-View-Presenter, Application Controller, Model-View-ViewModel, etc.
You can perform automated tests of an entire application via such interfaces, bypassing only the GUI rendering part. Such tests are called Subcutaneous Tests, but are considered Integration Tests, not unit tests.
Have heard about mocking frameworks. Are they also for unit testing?
Dynamic mock libraries are only for unit testing.
Some good and popular ones are
I'd suggest you to read 'The Art of Unit Testing', by Roy Osherove. I strongly recommend you to read Parts 1 and 4.
Although focused on Unit Testing (duh) there are some well-explained concepts that really helped me to understand better the world of testing. It's not a complicated / boring book, I enjoyed reading it even without any previous testing knowledge. Hope you enjoy it too.
About unit testing here is very good book: http://www.amazon.com/Art-Unit-Testing-Examples-Net/dp/1933988274
The Astels book is a solid introduction, Beck's book is good on the underlying concepts, Lasse Koskela has a newish one (Test Driven: TDD and Acceptance TDD for Java Developers). Osherove's book, as he says, is about Unit Testing, rather than TDD. I'm not sure that the Pragmatics' TDD book has aged as well as their original book.
Most everything is Java or C#, but you should be able to figure it out yourself.