3 ms·

Test Driven Development (TDD): Example Walkthrough

• dalke 13y ago
  As is often the case, when I read TDD walkthroughs, I see differences between the design, as implied by the tests, and implementation. Consider requirement 2, which is "For an empty string the method will return 0" One of the code changes was from: for (String number : numbersArray) { Integer.parseInt(number); // If it is not a number, parseInt will throw an exception } to: for (String number : numbersArray) { if (!number.isEmpty()) { Integer.parseInt(number); } } Oddly, the commentary doesn't even remark on this change, saying only "All there was to do to make this test pass was to change the return method from void to int and end it with returning zero." This is incorrect. Certainly the code passes the test. But as a consequence, the input ",5" is now acceptable, and will equal 5. Since the spec doesn't define what a number is, one can argue that it's reasonable that "," means 0. I disagree with that judgement, or rather, I'll instead argue that "one,two" should give 3, since "one" is certainly a number. ;) That's okay. Ambiguities happen all the time. Either the spec needs to change, or a test need to note that it's made an implementation-specific choice not guided by the spec. But it still requires analysis to determine the impact on the overall goals, and that analysis is often missing from the TDD walkthroughs I've read. The problem comes when this code is put into use. This change will also accept " 3, 1" as input, which might happen if someone used a "%3d,%5d" as a format string. Other code will start depending on this undocumented implementation-specific feature. The future developer who comes in, refactors the code, finds that it passes all the old tests, will be annoyed to find that it fails during integration or deployment.