Coder

Unit Testing 2

Continuing with the unit testing thread...

In the context of unit testing you can't view the interface of a component by itself. There are three parts to consider:

            interface
             /       \
            /          \
   component          client
   a.k.a owner       a.k.a. user

So you have to consider the following: (note that interface and owner are usually (and safely) considered to be that same thing)

interface
The syntax and semantics of the function, i.e. what the parameters should contains, are there sized pointers, etc.

owner
The implementation of the functions, e.g. is there a unique algorithm or data structure used, how does that affect boundary conditions, etc.

user
This last part is the one that is largely ignored. Its is important because if you test a unit like you would a system then you need to cover a large part of the input domain and expected output domain. But think about this for a moment: the client already has this coded up. This client is usually a component in the layer in the higher level (of abstraction).

So what I'm saying is that you can't look at a unit's interface and dream every possible input and expected output. This domain needs to reduced to a manageable size. This is done by leveraging what the client is already doing: calling your unit's interface with some input and processing the output. And this needs to be done with every client of your component.

Unit Testing

So I've been overhearing things like "unit testing", as in "we'll let you write a script to do generic unit-testing".

There's a problem with this. Let's say a unit is some software component with a coherent set of functions. This set of functions is the component's interface. Now the notion of generic unit testing implies testing the interface meaning testing a.k.a. the set of functions. However, it doesn't make sense to do this generically.

Let's the component is the front-end of a compiler and one of its functions is Compile( filename ). I cannot see how this can be sensibly tested in a generic way. You can't just use random data for the filename parameter. Also there is no way to guarantee that this function will get called first. In order to that you are specifying semantics of the interface which by definition makes the test non-generic.