【TDDを再定義したほうがいいって話だったのさ】UncleBob, Martinfowler, DHHのツイートまとめ

DHH @dhh

@unclebobmartin @bdruth @pragdave They may well be doing it wrong. Or overemphasizing TDD's role. Nobody seems to object though.

DHH @dhh

@unclebobmartin @bdruth @pragdave "If it isn't easy to test, or the tests can't be fast, it's bad design" is a prevalent fallacy.

DHH @dhh

@unclebobmartin @bdruth @pragdave As is "if you're not doing test-first, you're not a professional". Don't find that helpful.

DHH @dhh

@unclebobmartin @bdruth @pragdave But I do find your "don't be afraid of your code or changing it" very helpful. Regression protection +10!

DHH @dhh

@unclebobmartin @bdruth @pragdave And I prefer to work on common ground. So that's a banner I'm fully behind! Rails can do more for it too.

DHH @dhh

@unclebobmartin @bdruth @pragdave Maybe all we need is a TDD 2.0 :). Focus on the eradication of fear, enable confident changes. Less design

DHH @dhh

@rtlechow @unclebobmartin @bdruth @pragdave I don't believe that. Plenty full coverage apps have shit design, some no test apps have great.

DHH @dhh

@rtlechow @unclebobmartin @bdruth @pragdave At least if you define confidence as "passing tests". Integral confidence is a different matter.

Martin Fowler @martinfowler

@dhh @unclebobmartin I've always felt that self-testing code is the most valuable outcome of TDD. I often find design aspect useful too.

DHH @dhh

@martinfowler @unclebobmartin Main contortions I see in the Rails world are around trying to isolate controller tests and prevent DB access.

DHH @dhh

@martinfowler @unclebobmartin Which lead to some IMO seriously convoluted architectures with layers of cognitively expensive indirection.

DHH @dhh

@martinfowler @unclebobmartin The path from TDD to hexagon as it pertains to Rails is one of the clearest examples of that.

Martin Fowler @martinfowler

@dhh @unclebobmartin Neither of which is something I consider to be part of TDD. (Using a double for DB is common but not necessary)

DHH @dhh

@martinfowler @unclebobmartin I respect that Bob has a very different opinion on the key objective of architecture, though: delayed choice.

DHH @dhh

@martinfowler @unclebobmartin They come with the territory of test-first isolation and outside-in mocking. As well as the speed focus.

DHH @dhh

@martinfowler @unclebobmartin And even outside those forces, I consider the test-first approach overrated as a design driver. Rarely fits me

Martin Fowler @martinfowler

@dhh @unclebobmartin There are some TDDers who use mocking heavily. There are many who don't. I know TDDers who test Rails AR as you do.

DHH @dhh

@martinfowler @unclebobmartin Which wouldn't be as much of an issue if TDD wasn't sold as a pro/am divider, but it is. Not just helpful view

DHH @dhh

@martinfowler @unclebobmartin Right. Which brings us to a more fundamental discussion: which practices are essential to TDD, which not?

DHH @dhh

@martinfowler @unclebobmartin And it relies on the definition of "unit test" too. I agree with "case runs independently of other cases".

Martin Fowler @martinfowler

@dhh @unclebobmartin I think it would be an interesting discussion to explore how different teams do their testing.

Martin Fowler @martinfowler

@dhh @unclebobmartin I agree with you that the whole "unprofessional" angle gets annoying.

DHH @dhh

@martinfowler @unclebobmartin But very often "unit test" is presented as free of collaborators or context. Hence no DB and no controllers.

DHH @dhh

@martinfowler @unclebobmartin Yes, range of acceptable TDD is too narrow. And it's IMO harmful to mvc web apps. Much conceptual overhead.

DHH @dhh

@martinfowler @unclebobmartin BUT, I stand fully behind the wonders of automated regression tests. Love the "don't fear your code" angle.