开云体育

I think my response would be somewhat similar to that of the comments. (FYI, to make the comments visible click the link that says "25 responses" below the article.)

For starters, it's worthwhile remembering that different people mean different things by TDD- at the coarsest level of granularity, there's the "Chicago"/"inside-out"/"bottom-up"/"classical" and "London"/"outside-in"/"top-down"/"mockist" approaches. Each of these approaches given the same set of requirements would not only lead to very different test suites, but likely different code as well, so I'm not a fan of anyone claiming that "this is TDD, and people who don't do this don't understand TDD."?

That being said, I'm not sure adherents of *either* school would necessarily be entirely happy with the thrust of the article. London school proponents might begin by writing down an acceptance test of the kind described by the article, but then are very explicit about using unit tests (in the purest possible sense of the term) to drive 'internal code quality'. They would explicitly reject the premise of the article that tests should not dictate the design of the code.

Chicago style proponents might also start with an acceptance test. Unlike the London school, I guess it is possible in principle to test-drive an application for correct working entirely through system level tests, written in terms that would make sense to the end user ("click on this to see a modal with this text", etc.). However, in his book on the subject Kent Beck is very explicit that he would still practise TDD on smaller units even if such a comprehensive suite of acceptance tests were being written. The reasons he gives for this are short feedback times between writing code and running the tests, and to simplify the internal design. This would reflect my understanding of what TDD is and the advantages it offers.?

The only caveat I would express here is that Beck was writing in an era of Smalltalk GUI apps, under the assumption that without "programmer tests" (tests of small units of code, as the article cautions against) the time taken to write a system-level test and get it passing is measured in days. If I think about a modern Rails app, for some simple functionality it might take an hour or less to write an integration test and the code to make it pass, so this might change that calculus. Nevertheless, this is a professional judgement call. I don't think that the decision to write unit-level tests in this situation would reflect a lack of understanding of TDD on Beck's part.

Rob