Monday, February 11, 2013

Unit Testing and Mocking

I started unit testing with junit when I was a Java programmer. The capabilities of jUnit is helped me to verify the specific unit of code against determined state.
When it comes to Microsoft platform I came across with several unit testing frameworks which are often used. Each of the framework is having its own advantages and disadvantages. Software engineers are having different views and have no clear idea about what platform is most appropriate for their project. so I decided to research on unit testing frameworks available today.

Most of the companies try to choose the best unit testing framework and searching will go for weeks and months. Without having a clear idea about what they are going to achieve from a unit testing framework, search for best unit testing framework is purely useless. Each of unit testing framework is good for some aspects. But almost all of the frameworks support common features which are needed. Following is a feature comparison of some of the .Net unit testing frameworks available in software space today.


Classic or Mockist Testing

One other leading topic between developers is the use of classical method of testing or mocked testing.
The classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing.
A mockist TDD practitioner, however, will always use a mock for any object with interesting behavior.
For me both techniques have their own pluses and minuses. But I am a fan of classic style of testing as long as I am testing unit of code. Classic style of testing have following benefits.

1. Easy to maintain tests with ever changing code base. Tests are written with real objects, so any logical alteration will causes the unit tests to be updated.
2. Easy to identify and trace the point of failure.

But they sometimes classic testing having some overheads of maintaining Test Fixtures. Creating these test fixtures will add overhead to the testing.
In addition to that classic testing only verify the state of the SUT. If you are interested in behaviors of SUT then mocking approach is the option.

Let's see what scenarios will be most suitable for Mocking approach.

Following are some of the situations we should go for Mocking.

1. real object has non-deterministic behavior. eg. cache
2. real object is difficult to set up
3. real object has behavior that is hard to cause (e.g., network error)
4. real object is slow
5. real object has (or is) a UI
6. Situation when we need to test the behaviors
7. real object does not yet exist

These analysis paves our way to decide what type of unit testing best suits our strategy. We can not draw a clear boundary.
If you are not testing behaviors or do not have above mentioned complex situations, my advice is to use pure classic style of testing.

Other situation I will be using classic unit testing combined with mocking whenever needed(tests which can not be done using real objects).
I was struggling with MVC4 razor when binding a list of objects back to model when posting back. This is not just a single object but object hierarchy with lists inside it. I used templates but I used template for the parent object having the list. Then I manipulate foreach inside the template. This didnt populate the return values during the post back. I even tried old way which I used during Java Struts which uses html names with array notations. but failed. But after going through following article I found that my mistake was not allowing MVC to handle..

 It worked nicely.
 http://stackoverflow.com/questions/12844763/getting-a-list-of-radio-button-values-in-asp-mvc-3/14825180#14825180