Giving up on test-first development

And certainly TDD is harder as you approach the GUI, you want to test in vague ways which don't break with every change. If you thoroughly test all of the underlying behavior, implementing a GUI is typically incredibly trivial because everything beneath it is known (and proven) to work. Most of the article is not related to the GUI.

> ...it doesn’t work very well for a major class of program problems – those caused by unexpected data.

This is a hollow argument. Regardless of development methodology, if unexpected data isn't considered at all it could have all kinds of side effects.

Regarding conservatism with breaking tests (many tests failing for one change), it's likely the result of a structural problem within the application if it's an intimidating number of failures.

> It is easier to test some program designs than others. Sometimes, the best design is one that’s hard to test so you are more reluctant to take this approach because you know that you’ll spend a lot more time designing and writing tests (which I, for one, quite a boring thing to do)

Not sure how this applies to TDD, if you're writing tests first you aren't deeply concerned with designing tests because you're imagining what the interface for well-designed code would be, and then you write it. It frequently sounds like the author jumps into writing tests without any forethought.

> In my experience, lots of program failures arise because the data being processed is not what’s expected by the programmer. It’s really hard to write ‘bad data’ tests that accurately reflect the real bad data you will have to process because you have to be a domain expert to understand the data.

If you don't understand the variety of inputs, how can you possibly validate them? Programmers should have some domain understanding, certainly program inputs fall within that realm.

> Think-first rather than test-first is the way to go.

I agree; but step 2 should be testing in my opinion. Test first is just the first tangible work product, it isn't a ban on thinking.

You're ignoring the fact that tests aren't only to validate "end user functionality". They're also there to make life easier for the developer; to make both initial development and maintenance easier.

If I need a custom sort algorithm for my product, I'm going to write unit tests for it's implementation. I'm also going write functional tests to make sure the end user is seeing things sorted. However, those tests serve different purposes.

The unit tests allow me to write clean, simple tests that show exactly what the implementation is supposed to be doing for different inputs. That allows me to change the implementation of the sorting algorithm later and worry less about breaking the functionality.

The functional tests are (generally) not going to be as clean and obvious, nor cover every possible partition of inputs that the implementation could get.

That's the beauty of TDD. It forces you to sit and work out, "What is this code supposed to do from the client perspective?"

It battles the all-too-prevalent developer inclination to just start running with implementation without even taking the time to understand what problem is being solved.