开云体育

On Thu, Sep 3, 2020 at 12:31 AM, Walter Prins wrote:

Note that the context here is not greenfield TDD but bringing existing code that starts entirely without tests into testing and refactoring along the way initially via characterization tests etc.? The comment above should not be read without that background context as it could otherwise be potentially misleading.? -- Given you start with code without tests there's going?to be some tests being written after the fact, though then even still, you could argue that you could/one should start TDD'ing at the point where you have your characterisation tests and start refactoring towards a new object (say), which if done in that way, would mean you should not then end having to further write "symemetrical" unit tests after the fact.? Perhaps that was your point and I'm just slow catching on.? Still, for the benefit of others just mentioning the context as I initially read this and got slightly the wrong idea without that context.?

I don't actually think this is what he's saying here. He's describing a situation in which a class has been developed with TDD, and has good coverage, but it's growing too large and taken on too many responsibilities. In the "refactor" step of TDD, the solution to this problem is to extract a class that is responsible for one of those responsibilities.

Whereas I'd probably be comfortable treating this extracted class (he calls it a "child", at the risk of terminology colliding with inheritance) as an implementation detail of the "parent", and not writing a unit test for it, he seems to take it as axiomatic that it requires its own "symmetrical" test. (Exactly what he means by symmetrical is documented at?. That wiki is a whole other source of interesting reading.) This is why that section is called "Characterization Tests of Greenfield Code" - because the child class has not itself been developed by TDD.

Having said that I wouldn't immediately bother writing a dedicated test for the child, I think you really see the value of his approach when the child develops a second client, (or more) and then a behaviour change is required in the behaviour of that child. If the behaviour of the child is tested through its clients, then each test of those clients that depends on that behaviour is going to need modifying, which is drudgery. If, by contrast, you write a test at the level of the coordination between the child and its clients, then they don't need to be affected by the change in the child's behaviour. This approach, however, obviously depends on the child's real functionality being covered by its own test.