[LRUG] Dependency Injection and DHH

[Paul Robinson]

On 28 April 2014 14:08, Stephen Henderson <stephen at cognitivematch.com>wrote:

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.



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.

Working alone and intend to do so for ever? Why bother documenting
behaviour through tests when comments have done you fine so far?

Increasingly complex code base where it's hard to understand interactions?
Use a functional programming style and the complexity might just slip away.

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.

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.

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.

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.

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140428/b4ad6273/attachment-0003.html>