Re: How would you respond?
|
I can see how those paragraphs can be ambiguous. I didn't originally read them the way you are reading them now.?
As for the tests dictating the design. I think this is where most people get stuck. (e.g. they start writing posts about how TDD is an antipattern) The tests help guide the design, and help you see if your design is working. But the art in TDD is finding the next test which forces the code to move towards the design you want. It doesn't dictate the design by forcing the implementation, it guides the design by enforcing the desired behaviors, and helps you check that the design is correct.
Quite possibly. I'd trace this back to the article, with a couple of paragraphs quoted by way of example:
"test if x will be returned when a and b are added together"
The above language is not useful to anyone, unless you¡¯re building a calculator. But this kind of language is present in a lot of test code that specifically targets methods and therefore coupling it with how a particular class may work.
"test if confirmation modal appears when submit button is clicked"
This test case is geared towards a frontend facing software. The above test doesn¡¯t care how you got there, only that you got there. This makes it a flexible test case to implement as any changes behind the scenes won¡¯t break the testing suites.
When software is test driven, it means that the development workflow is focused on producing a set of particular results that emulate the needs of its consumers. It¡¯s about fulfilling requirements ¡ª not creating requirements for how to structure and produce your code ... At its simplest, proper TDD is an abstraction of user requirements.
?
And the final paragraph
This is basically TDD ¡ª testing to see if your software produces an expected, higher level and clearly specified expected result. The test merely catches the break ¡ª it doesn¡¯t and shouldn¡¯t dictate the design...
That¡¯s basically the core principle behind TDD.
Given that there are people out there who would argue that TDD is a design activity *before* it concerns itself with having tests to catch regressions, this last point is in my view an inappropriately strong claim to make, and represents my biggest problem with the article. In particular, if tests don't drive the design of the code, and aren't being used to anchor down the behaviour of small units, then I'm not sure what argument the author offers in favour of writing the tests before the code, which is pretty much the only thing that unites different TDD practitioners of all stripes AFAICT.
|
