[nybblesio]

It's a shame Kent used the words "test" and "development". Test Driven Design would have been better, but people would still misinterpret what is under "test". Yes, there's a side effect of asserting behavior in Kent's vision of TDD but it's a happy accident.

What's under test is the design. Way before TDD was a thing, when I worked at IBM, we used to call this "inverted design": write the calling code first to see what the API might look like and then make it work. In the late 80s it would have been considered a massive waste to assert behavior though; we'd just implement it.

Automated functional tests (from the outside in) are where the bulk of does-it-do-what-it-says-on-the-tin testing should happen.

[ragnese]

> Way before TDD was a thing, when I worked at IBM, we used to call this "inverted design": write the calling code first to see what the API might look like and then make it work.

I really like the idea of this, and I very occasionally have the foresight and wherewithal to do this kind of "top-down" programming.

Maybe not surprisingly, this is how I sometimes end up with the much-criticized "Interface with only one implementer" design smell. I write the interfaces that I would like, right next to where I'm writing the calling code. The interface(s) evolve as the calling code is unfolding. Then, later, I make an impl for the Interface.

At that point I could just delete the interface and only use the concrete implementation, but... I don't. shrug.

[spc476]

I don't think so. If I didn't know who Ron Jeffries was, I would have sworn the following series was pure satire about TDD:

    https://ronjeffries.com/xprog/articles/oksudoku/
    https://ronjeffries.com/xprog/articles/sudoku2/
    https://ronjeffries.com/xprog/articles/sudokumusings/
    https://ronjeffries.com/xprog/articles/sudoku4/
    https://ronjeffries.com/xprog/articles/sudoku5/