Unit testing - When and why?

Developer
Oct 8, 2012 at 11:43 AM

I startet coding on this project some days ago. Diving into someone else's code is always an adventure. Having a set of well designed unittests is good guidence to get an idea of what is nedded and expected from the available/adapted/new 'system'-code. In my oppinion it is also important to keep up the quality and consistancy of your testcode to achieve this goal.

My small first contribution is to implement one of the missing DeviceWorldTransformer. To get this done, I started by adding and adapting the relvant unittests in zTST_DeviceWorldTransformer_CommonBehaviour and newed a zTST_DeviceWorldTransformer_LeftUp class ( I love TDD :-) ). Then it is pretty easy to add the missing functionality on a method per method base. In this case I could copy almost 99.9% of the needed code from available classes. But doing it in a test driven way gives you a good understanding of the code lines you use.

In the end all tests are green! Great! But to my surprise, i didn't use all of the code, which was present in already available DeviceWorldTransformers. The first part was:

Private Property Set NV_IDeviceWorldTransformer_WorldDefinitionArea(ByVal Value As NV_WorldRectangle)
   If Value Is Nothing Then
      Err.Raise 5, , "WorldDefinitionArea must not be Nothing."
   End If
  ...
End Property

Here its obvious to me, that its a good Idea to test a property setter to check its validity. So in this case I added a test (which was already coded for checking other Property Exceptions). All other Transformers passed this test too. So no harm done with this change...

But the other one is more difficult to judge for me:

Private Sub NV_IDeviceWorldTransformer_Initialize(ByVal DeviceDefinitionArea As NV_DeviceRectangle)
'   Set NV_IDeviceWorldTransformer_DeviceDefinitionArea = DeviceDefinitionArea
'   MeAsTransformer.SetWorldForUniformTransformation
End Sub

I never uncommented the 2 lines above (which are coded in all other DeviceWorldTransformers too). This was the first time now that I tested my code with a 'real world' Form and not only with unittests. Using the provided Playground the new code seems to work correct. This leaves 2 interpretations:

a) The Initialize methode is not used at all. Maybe it was in former versions. As it is dead code now it should be removed from all Transformer classes (and from the interface!).

b) The Initialize methode is not used in the Playground context, but it is a well designed way to set up the Transformers parameters. In this case there should be a test covering its functionality. (In my interpretation it sets up a 'world' which is e 1:1 representation of a 'device')

I know that I could go and check if option a) could be true by going through the rest of the code base on my own, but this is not my point. My point is that this code is an excelent example of how much you can communicate with clear code and clear testcode. The above question about overall design and architecture is the only one I found here. This fact proofs to me that the functional encapsulation is really very good and that unittests do communicate a lot more than: 'somebody did a lot of work'. It also shows how important it is to keep the testcode in good condition, and that the 'nonexistance' of sth. also communicates much.

@Baula 1:  I asume that b) is the right interpretation and that we (I) will write the little extra unittest, correct ?

@Baula 2: in the end it was more a blog than a discussion starter. Feel free to move this feedback somewhere else on this site (or in the trash can ;-) )....

Coordinator
Oct 8, 2012 at 8:41 PM

Hi Rokos,

thank you for your time, effort and expertise you are spending with this project.

Regarding your question.

The method IDeviceWorldTransformer.Initialize() is called in the DeviceWorldTransformerFactory. The reasoning behind it is to initially provide a one-to-one mapping between world and device. This should keep the entry barrier low for those developers who might not even be aware of this device world thing. As you noticed, the Initialize()-method is not covered by a test. The reason why you did not miss them was probably because you did not play too much with changing the orientation around. Having this method not covered is far from being perfect, but I can live with it. If you feel more comfortable with these tests in place, I would of course welcome them.