Read this great article about unit testing wisdoms, thought its worth sharing.

The Way of Testivus

• If you write code, write tests.
• Don’t get stuck on unit testing dogma.
• Embrace unit testing karma.
• Think of code and test as one.
• The test is more important than the unit.
• The best time to test is when the code is fresh.
• Tests not run waste away.
• An imperfect test today is better than a perfect test someday.
• An ugly test is better than no test.
• Sometimes, the test justifies the means.
• Only fools use no tools.
• Good tests fail.

RWendi

Visual Studio 2008 comes with a unit testing tool, MSTest. The coolest thing about MSTools is that it integrates so well with Visual Studio. Every time you build your solution, Visual Studio will automatically run your test projects and display the results in a nice graphical user interface (similar to NUnit’s one). I’ve been using MSTest for my side projects, until I found out that MSTest is not supported Visual Studio Express, which I have installed in my MSI Wind. Because of this limitation, I had to resort back to the good old NUnit.

After using NUnit again, I really missed MSTest integration with Visual Studio. NUnit provides a very minimal integration with Visual Studio, which requires you to create an external tool that points out to the NUnit console. When you run the NUnit tool, it will spit out the results into your Visual Studio’s output window. The simplistic approach works, but the problem with this is that I have to run it manually each time I run my build. It would be ideal to just have this automatically run each time we build our solution. Luckily, this can be automated by using Visual Studio macro and post build event. Here is how you do it.

Creating NUnit As A Visual Studio External Tool

First we need to create NUnit as a visual studio external tool. To do this, in Visual Studio, go to Tools > External Tools. You will be prompted with a form, in which you can manage all of the available external tools. Click on the Add button and fill in the form as follows.

You should fill in your form exactly as above, except for the Title field (if you wish to have different name) and the command field. The command field is the path to your NUnit console runner. Click the Ok button to create the external tool. Now that you have created it, if you go to Tools menu in Visual Studio, you will see NUnit in one of the available external tools. When you run the NUnit external tool, it will run NUnit through command line, and display it in your Visual Studio output window.

NOTE: the above will make NUnit runs all of the tests in the current active project. Thus make sure your active project is your test projects when running the tools. You can do this by having your test as your active file in Visual Studio when compiling. You can make it not to be bounded by your current active project by; hardcoding the arguments value to be your test dll and the inital directory value to be the location of your test dll. But keep in mind that the tool is not project/solution specific. That is, if you open up a different solution, it will still run the hardcoded value.

Automating NUnit Integration To Run After Compile

Now that you have the NUni integration set up, its time to make it run automatically after each compile. Here’s how you do it:

• In Visual Studio go to Tools > Macros > Macros IDE.
• This will bring up a the Macros IDE.
• On the left hand side there should be a “Project Explorer” panel.
• In the Project Explorer panel, double click on EnvironmentEvents module.
• Insert the following code in the module.

Private Sub BuildEvents_OnBuildDone(ByVal Scope As EnvDTE.vsBuildScope, ByVal Action As EnvDTE.vsBuildAction) Handles BuildEvents.OnBuildDone

    DTE.ExecuteCommand("Tools.ExternalCommand1")

End Sub

As you can see that the above custom macro tries to run an external tool by its order. Thus depending on where you put your NUnit tool, you might want to change the parameter of right number based on the order of your NUnit tool. For example, if your NUnit is the third external tool, you can change the macro to this: DTE.ExecuteCommand(“Tools.ExternalCommand3”).

Debuging Your NUnit Tests.

Now that you have everything set up, how can one debug their NUnit tests? Surely you want to debug your tests once it fails. Here’s how you do it:

• Right click on your test project and select "properties”.
• On the right hand side, click on the Debug tab.
• Change the start action from “Start Project” to “Start External Program”.
• Insert the path to your NUnit GUI runner as your External Program.
• In the Start Option section, insert your test dll, as your command line args, followed by “ /run”. For example: “tests.dll /run”.
• Lastly set your working directory to the path of your test dll.
• Your form should look something like this.

With this configuration set up, whenever you run your solution (don’t forget to set your test project as your Start Up project), this will run NUnit’s GUI runner to run your tests. Moreover, Visual Studio will automatically attach the debugger to the NUnit’s GUI runner process. This means that you can start debugging by putting breakpoints in your test code.

Wait a minute, isn’t this another way of automatically running NUnit after compile? Yes it is. So why mentioning the “External tool” method? Well the problem with running NUnit as external program is that, you have to always run your solution (F5) and set your test project as your start-up project. Doing it as an external tool, you can just build your solution and it runs your test automatically. Moreover, I find that NUnit runs much faster in the “External tool” method.

Hope you find this useful. Now write some TESTS!

RWendi

In my work place, we currently do not write unit tests. I think this is one of the thing that we are very lacking of. The importance of unit test seems to be neglected by the management people. In fact, I think most business people don’t care so much about unit testing. Even my development manager, who comes from a technical background, doesn’t think that writing test is all that important. I remember talking about unit test with him and he said that as long as it doesn’t add too much of the total development time, by all means do it. I guess its understandable why management people seem to neglect unit test, its because they have the pressure to release software on time.

But, there is one thing that they forget or unaware of, which is Unit test improves code quality. I would see it almost similar to having a quality assurance (testers) in your team, only cheaper. With quality assurance, you know your product is ready to ship with good quality if it has been approved by the quality assurance people. Its sort of the same with unit test, developers will have the confident that they have written a good quality code if it passes all the unit tests. It can not get any simpler than that. Unit tests give the ability for developers to jump in and make changes without having to worry of breaking anything.

Sure you can throw in the argument that writing unit test will add more time to the development, but note this, as your unit tests grow your code base will be easier to work with. Code base that’s easier to work with, will speeds up development time. Thus in the end, all the time invested to write unit tests initially, will eventually pay off. Depending on how good and comprehensive the unit test library, cases like bugs regression can be greatly minimized, which means less time will be wasted on reworks. Moreover, unit tests can be automated which saves a big amount of your developers time.

Another argument that’s usually brought up by people would be unit test is hard to maintain. This is a very big misconception of unit tests. The fact is: Maintaining unit tests is not any harder than maintaining your code base. Similar to software design, unit test should be written in a way that it is persistent to change. Badly design test needs to be changed whenever there is a change in your code base, on the other hand well designed test is more persistent to code base change.

I’m going to quote Uncle Bob’s statement that says:

“If you design your tests such that 10% of them fail due to a single point change, then you need a new career. Test design, like any other part of software design, is about decoupling.”

Its a very good and true statement, except for the needing a new career part (that’s a little bit too harsh). I think what uncle bob is trying to say here is that well designed unit test is hard to break, and in essence designing test is similar to software design. Unit test is not all about writing them, its about designing them too.

I hope that one day people would realize that unit test is not a waste of time. Its a very important aspect in software development, which will improve code quality and development time. It may not show the result right away, but in time it will.

RWendi