I am a C# winforms developer with an experience of around a year. The only unit testing that I have been doing till now has been manual. I have thinking about following for
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
The why for automated unit testing is simple: because as your code grows, it will take longer and longer to do manual testing, which means you are less and less likely to do it.
By automating the tests, you make them convenient to run, so they will be run.
Point 1) It gives you a continuous overview of whats working and what not. As soon as you change a simple function you have the result if this change breakes anything. Furthermore you can later on refactor your whole application and as far as your unit test are all going green, everything works fine. Just this point is a very important one. Or have you ever done a project that had never to be refactored?
Point 2) NUnit is a good place to start, but there are several other unit test frameworks. Also i suggest to have a look at CruiseControl or other continuous integration tools that take much work off of the developer.
Point 3) Well, there are for sure people who can tell you hours and hours what to do and what not. As far as my unit test background is limited to use it for embedded devices we have quite other dificulties.
Point 4) C# is a programming language, not a testing framework. .Net has at least one Attribute that can help during unit tests, that is the InternalsVisibleTo-Attribute to make your internal classes and methods public for one spezific type.
Point 5) If you have a well designed application you dont have to test your gui. Think about this: your gui has no code. Every button a user can press is mapped to controller. Every input a user can provide is handed to the controller. So what do you have to test in your gui? All you have to do is to get your controller tested and working well. And with this MVVM/MVC/WhatElseArchitecture you have one the one hand a well designed application and on the other hand an application that is simple to test.
Very.
If I want to start doing automated unit testing. Where should I start from? (have heard about nunit) Start with nunit - its very easy
Do I need to keep anything in mind when designing my classes to facilitate automated unit testing? If you get good at unit test then you'll want to.
Does C# have an in-built support for automated unit testing? No - but Visual studio does - but I don't recommend using it
Can we also test GUI with automated unit testing or is it just business logic? Anything can be automated, its just question of how hard it is to do.
Have heard about mocking frameworks. Are they also for unit testing? Yes.
Read Roy Osherove's The art of unit testing.
To isolate parts of a program and show they are "correct". They are a contract if you will of how code is suppose to run. With this at hand they can tell you quickly and often if the code is acting correctly.
Unit tests enable programmers to change code more easily, with more confidence and less side effects. It promotes / enables refactoring of code which without unit tests can be dangerous. With all this in mind I find unit testing will make your code better.
I find them effective but will admit that this is part of the learning curve. Until you become really good at it (and I am still a beginner in my mind) you will often miss things but I have found it is still way better than the manual testing I have done for way too long. I found almost instant benefit in unit testing. On my first project with it I discovered that I was saving a large amount of time since I didn't have to manually test near as much and I was actually pleasantly surprised more than once when code I was working on caused tests to fail elsewhere that I wouldn't even had thought to retest manually.
Nunit is good, MbUnit is good. To get started, read and do the excercises in the readings. Websites and blogs on unit testing, test driven development (TDD), and Refactoring. Object Mentor has a nice series on TDD. Then at some point pick some code you have and try it.
Books I suggest - Test Driven Development by example, Test Driven Development, A practical guide, The Art of Unit Testing, Refactoring (Martin Fowler), Refactoring Workbook, Refactoring to patterns, Clean Code, and I am sure there are others.
I have refactoring books in the list because I have found the techniques to refactor work hand an hand with unit testing.
Many of the books I mentioned will discuss this. The answer is yes and no. Often a better designed class that has less dependencies is easier to test. This is just good design but it happens to make testing easier. There is a bit of a debate over if you should change code just to make it more testable. I lean towards you should. At this point for me, my code in the past didn't incorporate a lot of "good design" ideas so for me embarking on this TDD journey is increasing my awareness and level of good design in my code which is in part to wanting to do TDD.
If you have VS 2008 Pro, yes, or Team system but naturally I assume you don't.
Yes, there are several tools out there. Watin is one that comes to mind.
Yes. They allow for simulating/testing very complex objects that you can't easily unit test.
In my journey down the TDD path, I purposely ignored mocking in the beginning. For me, I wanted to have a bit of a better understanding of why they are needed and how they would be used by living without it and seeing for myself as I coded where I would get stuck with the traditional TDD techniques.
Another book I have found of great use, although it hurts my brain to read is Working Effectively with Legacy Code. It really shows you how seemingly innocent code to the untrained can make life really hard down the line.
Why do we need to have automated unit testing? How effective is it?
You don't. It is up to you to decide if you want to or not. It will only be as effective as you make it. You should go for automation only if your going to repeat testing cycle for a piece of code more than 3 times!!! If I want to start doing automated unit testing. Where should I start from? (have heard about nunit)
Whatever feels comfortable, make it your start point and then explore it and use it to your advantage. Can we also test GUI with automated unit testing or is it just business logic?
You can but you should not. GUI is better tested manually. Eyes will catch more errors in the interface than a machine will. Have heard about mocking frameworks. Are they also for unit testing?
Yes most of the frameworks like TestNG, Junit etc are for Unit Testing.