Test Driven Development (TDD) is a good methodology for writing robust code, but employing it doesn’t mean you’re free of bugs.
Say we’re tasked with filling in roundArray(), a function takes in an array of numbers and returns a new array with those original numbers but rounded.
Because we’re practitioners of TDD, we first write a test function Should_Get_Rounded() to verify that each element of the rounded array is rounded and that the original array is unchanged.
We run the test function and we find that the asserts fail, which means our tests didn’t pass with an incomplete implementation, as expected.
We now complete our implementation of the roundArray() function. We run the test function and find that the asserts pass.
All is good, right?
No, all is not good. For a function as short as seven lines, roundArray() is heavily flawed. For example, what happens when we call roundArray([7, 8, 9])? We get [0, 1, 2].
Looking at the JS docs, it turns out the for…in loop in JS does some pretty wonky stuff. For arrays, it returns the indexes rather than the values. Iterating over [0.9, 1.45, 1.78] would give 0, 1, 2 instead of 0.9, 1.45, 1.78. What we want instead is the for…of loop.
Here’s a better test and a working implementation.
We first improve the test by changing the values of the array (and the expected values in the asserts, too).
Then, we run the test. It should fail because our round function implementation is bugged.
We fix the implementation. In this case, we use the for…of loop instead.
Lastly, we run the test again. It should pass because our implementation is now correct. Nice.
Looking back, what was the problem?
Was it:
- Test Driven Development is a flawed methodology.
- With our Python background (or other), we wrongly assumed that for…in would loop over values instead of indexes.
- We only wrote one test with a special case where the rounded array values happened to be the indexes.
I’d say it’s mostly 3. Writing another test or changing the current test to have more varied numbers would have caught the bug. Number 2 is a problem, but it’s not something we could have easily expected. JS is known for its quirks.
But the point of all this isn’t as specific as “when testing array functions, you should use varied elements” or even “when testing functions, you should test varied inputs.” The point is, TDD doesn’t guarantee program correctness if you have bad tests. Hell, TDD doesn’t guarantee program correctness even if you have good tests. It’s a stepping stool to reduce mistakes in your code. Beyond that small boost it gives you, you’re on your own to be smart.
TL;DR
Don’t fall into a false sense of security with TDD. Be mindful and do your best to write good tests. That’s all.
