3 ms·

> I won’t spend ridiculous amounts of time writing tests when I can read the code and clearly understand what it does. Is he arguing that simply trusting yours

> I won’t spend ridiculous amounts of time writing tests when I can read the code and clearly understand what it does. Is he arguing that simply trusting yourself not to make mistakes is a sufficient guarantor of quality? Ian Sommerville is the author of a famous textbook on software engineering, so it would be surprising if he was. TDD is actually much more difficult in practice than people realise. I read Kent Beck's book and thought it sounded like utter horseshit. I tried doing it myself and decided it was definitely horseshit. Then I came to work at Pivotal Labs. Now I am distrustful of code that was written before tests. As for the argument that TDD distracts from the big picture, this is like saying that indicator signals and mirror checks distract from driving. Sure, when you are learning to drive, you feel so overwhelmed by attending to all the little details that you struggle to drive at all. You become unable to focus on your navigation. After a while you learn the skill and it becomes automatic. TDD is such a skill.

Chris2048 11y ago
What changed at Pivotal labs? And what do you get with regards to specs? It seems to me the methodology fits how requirements are derived.
- jacques_chester 11y ago
  > What changed at Pivotal labs? The bread and butter of Labs is teaching people pair programming and TDD. So I was taught those things, and I'm still learning. It takes a few passes through the whole cycle of story->feature test->integration test->unit test for things to begin to click, for that way of thinking to become habitual. It is uncomfortable and frustrating for some time, as Ian Sommerville found. In fact, because most code is not written test-first, it is difficult to test. So all that keeps you to TDD is habit and, to some degree, help from another engineer. > And what do you get with regards to specs? It seems to me the methodology fits how requirements are derived. The most popular story-writing style I have seen so far is the As A/I Want/So I; Given/When/Then. Usually some acceptance criteria are supplied. To varying degrees of fidelity that the feature tests will typically follow Given/When/Then. In our weekly Iteration Planning Meetings engineers are expected to pipe up if there are useful ways to decompose stories into smaller stories, which makes the overall situation more manageable.

Chris2048 11y ago

What changed at Pivotal labs? And what do you get with regards to specs? It seems to me the methodology fits how requirements are derived.

jacques_chester 11y ago
> What changed at Pivotal labs? The bread and butter of Labs is teaching people pair programming and TDD. So I was taught those things, and I'm still learning. It takes a few passes through the whole cycle of story->feature test->integration test->unit test for things to begin to click, for that way of thinking to become habitual. It is uncomfortable and frustrating for some time, as Ian Sommerville found. In fact, because most code is not written test-first, it is difficult to test. So all that keeps you to TDD is habit and, to some degree, help from another engineer. > And what do you get with regards to specs? It seems to me the methodology fits how requirements are derived. The most popular story-writing style I have seen so far is the As A/I Want/So I; Given/When/Then. Usually some acceptance criteria are supplied. To varying degrees of fidelity that the feature tests will typically follow Given/When/Then. In our weekly Iteration Planning Meetings engineers are expected to pipe up if there are useful ways to decompose stories into smaller stories, which makes the overall situation more manageable.