Unit Testing and testing in general is one of the most neglected arts in the software business.
Hardware as Illustration
In a previous life I designed electronic hardware. Part of the project was always a test fixture and test procedure that would be used to demonstrate that the final product both performed according to its specification when supplied with in range stimuli and failed in a predictable fashion when supplied with out of range stimuli. The second is in a way the more important, for these reasons:
- in range behaviour is always part of the formal specification whereas out of range behaviour is often either not specified or is inadequately specified,
- in real life it is often not possible to ensure that all stimuli are within the valid ranges so knowledge of the device's behaviour as the boundaries are crossed enables us to decide whether or not it is safe to use the device at all.
For instance, imagine an uninterruptible power supply (UPS). This is a device that contains a battery, battery charger and an inverter. the inverter converts DC from the battery to AC that looks just like the normal mains supply. In order to have a smooth switchover from mains supply to inverter the two must be, momentarily, connected in parallel. For this to be safe the inverter output must closely match the mains supply in voltage, waveform, phase and frequency. This is not a difficult job but nonetheless certain precautions must be taken. In particular we cannot expect the inverter to synchronize to absolutely any frequency. Perhaps the mains supply is really a generator and when it starts and stops the frequency varies dramatically.
The inverter specification will say something like:
- the inverter will synchronize to mains supply frequencies between 45Hz and 55Hz.
Now by itself this is not enough because the behaviour of the inverter when the incoming mains is at 44Hz is unspecified. If we simply cease to synchronize what frequency will the inverter have? The specification we have given is silent on the matter.
Some people might at this point start thinking in terms of exceptions but this is not a good idea. The reason is that there is nothing exceptional about this condition, it is entirely predictable that such a condition could occur. See ThrowingExceptions.
The solution is for the specification to cover all eventualities. This sounds like a rather tall order but it is in fact not. To go back to our UPS; just add these clauses to the specification:
- if the frequency is below 45Hz or if the frequency is between 55Hz and 1kHz the the inverter will not attempt to synchronize but will revert to free running at 50Hz and refuse to connect in parallel with the mains,
- if the frequency is above 1kHz the behaviour of the inverter synchronizer is undefined.
Note the last clause. The point is that we can define a large enough area to cover those conditions that are likely (what counts as likely depends on the risks and consequences of falling outside the specification limits) and explicitly say that we do not guarantee any specific behaviour outside that range. This means that the user of the device can now be confident that the device will not cause safety problems even if the stimuli are out of range until they are so far out of range that the conditions can be regarded as exceptional. Here is where software exceptions can reasonably be used but note that you cannot raise one to say that the frequency is above 1kHz because you have specified that the behaviour is undefined (probably because you don't want to spend money on a more sophisticated frequency meter) so at 2kHz you have no knowledge of the frequency. The exceptions would most likely come from deeper in the system and indicate some other symptom. These exceptions could be interpreted as meaning that the frequency is above 1kHz but we must be careful of overinterpretation.
No comments:
Post a Comment