[rhizome31]

#2 and #19 are controversial.

#2 contradicts itself. It says that unit tests will make sure that code that already works doesn’t break but at the same time it won't help writing good code. Well as far as I'm concerned, code that breaks can't really qualify as good code. Writing tests first, or writing code to the tests is ridiculous. Not sure what writing code to the tests actually means, is that even correct English (I'm not a native English speaker)? The main benefit of writing tests first, is that tests do get written. It's too easy to say we'll write tests when we have time. If you discipline yourself to write tests first, by the time the code is written, the tests are written as well. Writing tests first also saves a lot of manual testing time (eg. clicking over and over in a UI), which is repetitive and stressful activity. Overall testing and TDD help a lot to achieve #11.

#19 is an amusing caricature, but misleading. Design Patterns are not limited to GoF patterns. They show up at different levels of abstractions and give developers useful vocabulary to communicate about stuff they do anyway. #19 mentions 2 patterns that are not very useful in our daily lives, but they are patterns like MVC, observer or iterator that we use all the time without even realizing they are patterns. The point of patterns (design, coding or architectural patterns) is not to memorize the GoF list but to learn to identify, label and share recurring solutions that we can reuse in various situations.

[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.

[henrikschroder]

> #2 contradicts itself. It says that unit tests will make sure that code that already works doesn’t break but at the same time it won't help writing good code.

No, the only thing you can say about the quality of code through tests is that if you change some code and it still passes the tests, then you didn't break it. The tests say absolutely nothing else, because their output is binary - pass or fail. They say nothing about the efficiency, readbility, complexity, or style of the tested code.

Tests can help take you from broken code to working code, and not a step further. To make it good code, you have to look at the code, not the tests.

[qu4z-2]

Technically, you only know you didn't break the tests.

But assuming well thought-out tests, that's a good indication that you haven't broken the code.

[Retric]

There are times when clean code that almost works is better than messy code that actually works. Generally when the requirements are still fuzzy. But also when your still deciding were to handle edge cases and such.