Part 5: Why test first?
30/12/2009
For the codebreakers, it was far tougher. Usually, they had an intercepted message with no known parts, enciphered on a device of unknown settings. Obviously there were no electronic computers to run tests either; everything had to be done by hand and mind; mathematically complex tasks having to be done repeatedly with complete accuracy. Some of this work was done by the leading mathematicians of Bletchley like Alan Turing or Dilly Knox, but much of the drudge work was done by "the Girls" of the Women's Auxiliary forces who were stationed at Bletchley. Someone doing such repetitive mathematical work at the time would be themselves called a "Computer".
But can we call what the codebreakers did "Testing"? Definitely. Whether by intuition, brute force mathematics or intelligence, the codebreakers produced hypotheses as to the key settings or partial content of a message, which then had to be verified. Some of this would be done manually by repeatedly entering hypothetical settings into an Engima machine (or a British Telex encoder set up to mimic one). Much of it, however, would be done on the electromechanical devices known as Bombes. Into these were fed "menus" of message conditions that had to be met. These were processed through parallel banks of Enigma rotors, and the vast machines would roar and clatter away until certain end conditions were met (or all possibilities had been exhausted), minutes or hours later.
One critical difference was that the codebreakers were testing multiple hypotheses until one fit. We want to create very specific conditions in our tests and have them all pass, all the time. To do so, we need to know not only more than the codebreakers did, but more than we generally do about our sites. We need specifics.
In some ways, what we're building are test *rigs* into which our code must fit precisely. There's no point writing the code (or building something physical) and then seeing if it fits the rig; we need to use the rig thoughout construction. To extend the parallel, we're not building the entire Enigma and then seeing if it works; we build a bit at a time (for example a cog or rotor) and check that it performs to specification. So, as well as being our rig, our tests are also our specification, and probably more rigorous and precise than we're used to creating.
If we built the physical Enigma piece-by-piece and then tested it, we'd probably be surprised if it all worked smoothly. If we finely tested each element and then each sub-assembly as we put it together, we'd very much expect success. This is exactly what we're doing with our code, allowing us not only to know that it *does* work, but how and why it works too. If something changes around a given module or sub-assembly, we can be pretty sure that it will continue to work; and if it doesn't, we'll know exactly what's failed and why.
As a side note, there was a department at Bletchley called the "Testery". This had nothing to do with testing though; it was the department led by Major Ralph Tester that first worked on breaking the Tunny ciphers.
In part 6, we'll start applying this idea of modular testing to the Rotors of the Enigma machine.
All content copyright Richard George (richard@phase.org), 2009-2010
Navigation
Contact
Sponsored links to recommended books: