Always write unit tests from get go

‘Always write unit tests from get go’, this is nothing new. If you are following TDD pattern then it is the default style. But when we develop an application which need to be delivered in a short time frame, if you do not have TDD background and testing is not the first class citizen in the programming tool set, before you know it, product will be delivered with no tests. This is always the case if there is no one bugging you about unit tests. 

Let’s talk about building a brand new application. Most of the time, when we develop a brand new application, our application will be very simple compared to what we end up with in three or four years down the road. Most of the time, our initial applications are very simple, which does nothing but bring data from back end and display it in the front end. Nothing much to it. When you have four or five line methods, why would you want to write unit test for it? It is a very bad assumption. You might start with this four line and as the application start growing these four lines might end up becoming twenty to forty lines (of course you might end up re factoring), you increased the complexity 10 fold. Now try to write unit tests and you will be stuck. There might some dependency that need to be removed and need to re factor the code so that we could even start unit testing. Now, unit testing becomes an explicit task which is going to consume time and effort. If you would have written the unit tests as part of initial development then as we add more code to it, our tests will also evolve and when we get to this twenty or forty line of code, there will be plenty of supporting unit tests for it. When someone is trying to modify this forty line method, it has good unit test to back them up so that they know they are not breaking any existing code.

One of the very important benefit of the unit testing which most of the people forget is that it can show you your design flaws very early on. If you are not following SOLID pattern then writing testing is little difficult. We always need to develop application in a loosely coupled model. All the dependencies should be injected into the code, which lends itself to a very maintainable software. If you were writing unit tests early on and if you were stuck on a place where you cannot do unit test, then you have a hard dependency problem or breaking one of the SOLID pattern. Since this problem identified early on, we can change the design to make it testable, we also reduced the complexity during the course of re-factoring. This is a great benefit of adding unit tests in the green field development. Write unit test for any and all the public methods, someone will thank you when they have to add a new feature to the same code after four years.

I hear people say, ‘I will come back and re factor the code and add unit tests’. Trust me when I say this, you are not coming back to re factor, you will have some other better things to do and never will have time to do it. Even if you were to come back to the code, how are you going to justify the task that could have been done in the first time itself? So here is a rule of thumb, if you ever say, ‘ I will come back to code to do something’, then you are knowingly adding tech debt to the code. Don’t just say it, do it. Do the re-factoring add unit tests, take extra effort and do it.  If it take some extra time to do it, I will ask you to talk to the managers and tell them the benefit of the re-factoring. If the managers do not understand (I really hope it is not the case), reach out to the technology leaders of your team. They will help you make the case.


NUnit vs MSTest

Couple of things I want to add on my observation on using MSTest vs NUnit. I always like to keep my deployment project and test project separate so that when I deploy my application there will be no test code sitting in production. By setting up a environment like this have a limitation when using NUnit. I might have some method private which if I want to test them using NUnit I can’t, since it can not find it. Only way I can test in NUnit is by exposing all the methods as public. On the other hand, with VS2010, I can right click on a private method and it creates test for me in the test project. So my class is clean and I am not exposing the helper methods as public. On this aspect, MSTest is awesome. This is a debatable . If you are creating API then you should be fine by exposing them public, but I do not like the idea to make methods public to support external tool. I like to keep the class clean. On the other hand,  MSTest lacks some of the simple fundamental assertion NUnit have, like collection assertion (without looking for separate method) and able to use TestCase to capture multiple test case against single test to keep the test DRY.

I am still using MSTest and NUnit in different project. MSTest along with Gallio really good, on the other hand, NUnit/NSpec/Growl is so cool as well. I hope MSTest will come up to speed on NUnit so that I can stay on MSTest.

Collection Assertion in MSTest and Kata

I have been doing Prime Factor Kata with one of my friend. If you want to follow along, there is a great video post at Rickard Nilsson blog. For this Kata, my first attempt was to use C# (obviously), NUnit. All worked very well. So out of curiosity, I decided to change it a little bit, use MSTest. I was expecting the same code I wrote in NUnit would work in MSTest but to my surprise, even my first test failed. Here is my first test

Assert.AreEqual(1.Primes(), new List<int>());

Here is the Primes implementation

public static List<int> Primes(this int n)
   return new List<int>();

Very simple. In NUnit, when you assert a condition on a collection, it just does assertion, while in MSTest, you can not use Assert against a collection.If you need to do assert against a collection, you need to use CollectionAssert.AreEqual. So when I changed the code to CollectionAssert, it worked like a charm. But here is a catch though, if I had the code like

public static IList<int> Primes(this int n)

The assertion will not work since IList does not implement ICollection, rather it implements ICollection<T>. There are ways to work around that, but I found a better way of doing the whole thing anyway. If you want to do it like NUnit, then, what I would recommend is to install NBehave. Specifically the NBehave for .Net. With that installed, now the same test I used in the beginning of the blog would be like this and more readable.

1.Primes().ShouldBeEqualTo(new List<int>());

Which is more readable and the same code works with NUnit and MSTest. The whole benefit of Kata for me besides the obvious, I was able to compare little bit of MSTest and NUnit. Based on what I have done, I decided to use NUnit just for ‘Parameterized Test Fixtures’. One of the thing we do while doing the Kata is code, refactor. It turned out, all my tests were copy paste except the input and expected result.So rather than have eight separate tests now I have one consolidated test with the input and expected result been passed in as attribute to NUnit. Here is the final code

[TestCase(1, new int[0])]
[TestCase(2, new int[1] {2})]
[TestCase(3, new int[1] {3})]
[TestCase(4, new int[2] { 2, 2 })]
[TestCase(6, new int[2] { 2, 3 })]
[TestCase(8, new int[3] { 2, 2, 2 })]
[TestCase(9, new int[2] { 3, 3 })]
[TestCase(3*5*7*11, new int[4] {3,5,7,11})]
public void Should_Find_Primes(int t1, int[] t2)
     Assert.AreEqual(t1.Primes(), t2);

Thats all about it, good way to start a new year by learning something new and cool.

Unit Testing in Silverlight – Continuing the path

In my previous blog I talked about few starter pointers for Silverlight Unit Testing. Hopefully you have converted all your Silverlight application fully testable by now. Now comes the next question, by default when you run the Silverlight test, it launches the web page and perform the test. It is all good and well as long as you are in your development environment, what if you want to run your tests as a part of your Continuous Integration (CI). There is a solution for that.

Fortunately I follow Jeremy Likness blog and some time back he wrote a blog about a open source project called Statlight. So today’s tip, if you want to run your Silverlight test as a part of CI, download and run Statlight. Please read Jeremy’s blog, he explains how to run Statight, so I am not going to duplicate that effort.

Unit testing in Silverlight – Starting points.

For all the starters who are venturing into Silverlight testing, I would like to pass on couple of pointers that might help in your testing endeavor.

1. Make sure you create test project using ‘Silverlight Unit testing project’ template to test your Silverlight application. Do not use ‘Test project’ template, it will add incorrect dlls and you will end up spend time trying to find out why in the world, there is version conflicts?

2. Most of all you might have Test Driven.Net installed in your Visual Studio, do not try to test a method by right clicking the method. Rather make the test project as start up project and run the project. When Silverlight test project runs, it gives an option run a specific test using Tags of the tests. Make sure you have a break point set in your test method and run only the test you want to run, it will take you back to your project for debugging.

3. You will run into a situation where you might want to read a data file sooner or later. This can be achieved in two ways.

One is embedding the items in request as resource at the client side.

The second approach is to put the required files in web site which is hosting your Silverlight test application and use ‘HttpWebRequest’ to load the files asynchronously. Loading data asynchronously is little tricky, but there are solution on the web. When you created the test project, if you choose to use dynamic hosting then the second approach is not going to work. If you decide to go with this approach make sure when you create the Silverlight Test Project to enable the check box to create web page to host the application. You can find the solution for loading files in Silverlight Forum. One thing to remember, in this approach your data files lives in web project.

I like the idea embedding the required files as long as they are not very huge. Also when you are using second option, your will end up writing your test methods in delegates. On the other hand, if you would use embedded resources, all you test will be in a single method.

Thoughts on Unit Testing

Yesterday I had a great conversation with one of my friend about few things one of them was Unit testing. He is a big proponent of Unit Testing. Good unit testing (see I did not write more unit testing) could  help identify and resolve the bugs in the code very early. This also helps code maintenance. I use unit testing where ever and when ever possible. I will not sit and break my head over how will I do unit test when I develop form over data patterns. On the flip side when you develop a program that involves some kind of logic that manipulate data then for sure you need to identify the components and test it.

This was one of my friend example, why would we need unit testing, lets assume _a and _b are variable and instead of doing if (_a == _b) if you would do it, if (_a = _b) then you have problem. If you would write an unit test for it, you will catch it early enough. On the side note, this condition will not even compile in C#, because compiler will complain, it can not convert integer to bool implicitly. Anyway, you got the point.

One very import point I want to make is how many unit test you write? Write enough to do good code coverage. If you have a method which takes bunch of parameters and you are asserting against some values, in older version of NUnit, you would write individual methods for each assertion. With latest version of NUnit you can write the single test and decorate it with all the assertion saves lots of code duplication. It also make code maintenance easy. So please check out latest version of NUnit.

If you are lazy or do not want to do unit test yet you need to do please your boss, here is a short cut, use Microsoft PEX. In this, you point a method and PEX will create all the possible scenario test cases with all possible input parameters.

Now that I am doing more and more Silver Light + RIA, I need to do more reading on how I can test the code good. Any of you are using testing for these platform, drop me a mail.

Technorati Tags: ,