[Chris_Newton]

Not sure what writing code to the tests actually means, is that even correct English (I'm not a native English speaker)?

It’s idiomatic, and it usually has a negative connotation. An analogous example is criticising a school for “teaching to the exam”, usually implying that the school’s teaching is inappropriately prioritising getting the student a good grade in their exam, at the the expense of giving the student a good general education in the subject.

Here’s a contrived example of writing code to the tests, in the negative sense. Given this test:

    def test_add():
        assert(add(1, 1) == 2)

we could write this obviously broken implementation of the add function, which is nevertheless the simplest code that passes the test:

    def add(a, b):
        return 2

[dripton]

Obviously your test case is insufficient.

In Kent Beck's "Test Driven Development by Example", he starts just like this, with an insufficient failing test. Then he writes a minimal function that passes it. Then he adds another test, then improves the function until it passes both. By the time he's done, he's got tests for all the edge cases he could think of.

I think it's a great way to make sure you cover all the edge cases, for a sufficiently complicated function. I don't have the patience to write all my code that way, though.

[Chris_Newton]

Obviously your test case is insufficient.

Yes, it is. The point is that even given many additional test cases of the same type, they will remain insufficient, unless of course you’re planning to test the entire input domain, which I imagine is going to take you a while.

Clearly at some stage you have to replace satisfying isolated cases with some form of generalised understanding. At that stage, you’re no longer coding to the tests.

This is not to say that unit tests can’t be useful. On the contrary, I find them a valuable tool for many programming jobs.

However, as I have observed before, the plural of “unit test” is not “proof”. I do find it frustrating when I see overconfidence instilled in too many developers just because they have a suite of unit tests available. Using TDD can’t magically guarantee that a program actually satisfies all of its requirements. Refactoring without thinking isn’t magically safe as long as the code still passes the test suite. Writing code to the test is not a substitute for understanding the problem you’re trying to solve and how your solution works.