From Wikipedia: “Mathematical induction is a method of mathematical proof typically used to establish that a given statement is true of all natural numbers. It is done by proving that the first statement in the infinite sequence of statements is true, and then proving that if any one statement in the infinite sequence of statements is true, then so is the next one.”

… then applying this to testing code … if a function received a set of inputs and then has an expected output, you could (theoretically) derive a formula representing the (mathematical) function of the (programming) function – and then test that the function gives the correct result for all possible cases of input values.

Testing end-cases, or extremities is also critical, particularly when dealing with very large numbers. I recently had a case where I wrote a script to extract certain posts (status updates) from Twitter and store them in a database – what I didn’t take into account was the extreme case of the twitter statusid (a unique integer assigned to every status update) incrementing to the point where it exceeded the bounds of a 32-bit unsigned integer. Oops. Because I was using a loosely typed language (PHP), my code didn’t break, but my database table was set to expect a 32-bit unsigned integer, and rather than throwing up an error when it received something larger, it instead reset the integer to the largest possible value … so the error I received was actually a “duplicate key” error, rather than what I might have expected – something like “number too large” (which in retrospect was a bit silly to expect, given how computers tend to represent large numbers).

Another point I think is worth making is that use-cases and user stories are all well and good, but in many cases, they only represent what the “user” (often a business user with little technical ability) wants or needs, with little regard to the future requirements. This can lead to code being developed which is non-portable and not very extensible.

Taking your example – if the use-case is that the integers will only ever be n=1 or n=2 (because this is what the company currently does), then your simple switch/if-then-else methodology would easily be the most elegant solution which meets all specified use-cases. However, if the company ever changes policy or through mergers and acquisitions faces a previously inconceivable value for n, then the code needs to be revisited to make it work.

If the code had been written to cater for more general cases, had been built with extensibility and flexibility in mind, then many of these issues would go away.

Of course, I guess this is the point of TDD to a degree – why waste time building code to cater for something which might not happen? Re-usability and elegant design is nice in theory, but you waste a lot of effort and introduce a lot of complexity coding for something that isn’t actually needed, and may never be.