Coding

There are some unit tests that should be run in a production environment. Sounds heretical, but wait a moment.

fsck is the Unix file system checker. It checks the file system and reports on errors. At heart it is just a unit test that looks for faults in the file system.

Quite a few unit tests can be written to do the same. For example, read a database and check that it is consistent.

Take a collection of bonds, price them and check the prices against an external source.

All of these tests work on large data sets and should be available in a system. They are particularly useful after an upgrade has been installed.

I have even written tests to check that a system has been configured in the correct way.

I've posted before on Fitnesse. Thinking more about it I think it does have one advantage over NUnit and unit testing.

When you are writing unit tests there are two ways that end up being used.

• Development phase - test first, then code
• Code coverage shows wholes in test strategy - code first, then write test
• Bugs - code first. Then when detected write the test to show its existance and a test to show it has been fixed.

In almost all these cases the test gets written with inside knowledge of how the code works. In the development phase there is a lot of iteration between test and code. Similarly with the test second approach.

Fitnesse is different. The tests get written without any assumptions as to how the code is going to work. That is a significant difference.

I'm getting really annoyed with some of the design of libraries, and in particular Dot-Net.

If we take the simple task of converting a string into an integer. Clearly we can expected strings to be passed in that cannot be converted into an integer. Dot-Net takes the approach of generating an exception. OK, acceptable practice so far. However, there isn't a method anywhere that enables testing of strings to see if they can be converted to an integer.

Public Function IsInteger(text as String) as Boolean

You have to write this function yourself.

Public Function IsInteger(text as String) as Boolean
    Dim i As Integer
    Try
       i = CDbl(text) ' or use the convert Class
       Return True
    Catch
       Return False
    End Try
End Function

To have to write this every time such that you can write code in this way

    If IsInteger(text) then
        ...
    Else
        ... ' Handle error
    End If

Is really really annoying.

Having an IsInteger function also means that writing unit tests becomes a lot easier.

It also means that you can attempt to put in place preconditions and post conditions in routines.

What is happening is that programmers haven't be brought up with Design By Contract where this sort of function is normal, because it will be used as a pre or post condition. This is one reason why the function should also be side effect free. If you know Eiffel then you will program this way automatically.

Similarly, they haven't thought about the need for functions in unit tests. Here you don't want to be messing around with exceptions unless you are testing an exception framework. You want clean code.

There is the implied connection between unit testing and DBC. Both are needed. Unit testing to exercise the code. DBC to test the code, when ever it is run, not just in a unit test.

I've been using NCoverExplorer as part of Testdriven.Net for some agile development. However, last night I found a bug. I sent the stack trace off to the support address. Grant writes back quickly. I send him some information about how to replicate the problem. New version is released within 2 hours of the initial bug report.

Thanks Grant. Appreciated.