<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 28 April 2014 14:08, Stephen Henderson <span dir="ltr"><<a href="mailto:stephen@cognitivematch.com" target="_blank">stephen@cognitivematch.com</a>></span> wrote:</div>

<div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Probably a better argument is that there's often too much focus on the “how to” side of implementing tdd/agile/xp/etc rather than the “why” side of understanding
 the root problems they address and how they can help reduce them.</blockquote></div><div class="gmail_extra"><br></div><br></div>That still isn't going to work when you're dealing with an isolated programmer who is both dogmatic about TDD/BDD having no value and who is either working alone or in a very small team on a (relatively) simple code base few others will ever go near. They might well argue that those root problems could be fixed through other techniques and strategies, and they could have a point.<div>

<br></div><div>Working alone and intend to do so for ever? Why bother documenting behaviour through tests when comments have done you fine so far?</div><div><br></div><div>Increasingly complex code base where it's hard to understand interactions? Use a functional programming style and the complexity might just slip away.<br>

</div><div><br></div><div>Want to refactor for performance but scared functionality will break? Manual testing and QA might be fine if you've split everything out into smaller modules.<br></div><div><br></div><div>Now of course all of those counter-argument can be defeated with specific examples. So in that sense, I think you're right that talking about why we do things the way we do them rather than looking at specific tools might be of benefit. </div>

<div><br></div><div>But we must also understand that there is no "right" way, only the way that works best with the problem domain, team and resources you have to hand.</div><div><br></div><div>In this, the arguments are a little like Agile methodology: if you're planning manned mission to Mars, it's perfectly acceptable to build your flight computer using a waterfall method because your problem domain isn't changing (the laws of physics should stay the same), the resource allocation is large (NASA-esque budget), and the cost of failure is high (you'll never work again, relatives will hunt you down, etc.). That's not the same design constraints as a website where the problem domain is changing day by day (competition, you're getting constant feedback, etc.), the resource allocation is deliberately kept small so you have to prioritise as fluidly as possible, and the cost of failure is more annoyance than it is life-threatening.</div>

<div><br></div><div>And so it is with TDD. There are some use cases where nothing less than formal proofs are going to suffice (fly by wire, nuclear power station safety control systems, etc.). And there are going to be occasions when common sense dictates you ditch everything but manual testing: I had one boss say to me that he would "rather have technical debt than, you know, actual debt" - and in the context he was using, he was right.</div>

<div><br></div><div>Most of the time though, you are right and TDD or BDD is a boon. So you need to understand the rules before you can confidently go about breaking them. </div><div><br></div><div>Knowing the "why" is therefore just as important (or more important) than the "how", and those people who argue one way or the other through actual code examples are missing the point that software development is primarily a game won by communication, and tests are asynchronous communication that help clarify things now and many years into the future - the most valuable form.</div>

<div><br></div><div>Therefore it really doesn't matter a damn if you prefer RSpec or Test::Unit, providing you're talking to your future self and colleagues through one of them.</div></div>