

Another reason you should be doing TDD - invalid_arg
http://mat-mcloughlin.github.io/2013/06/15/another-reason-to-do-TDD.html

======
jccc
This seems much less to be about TDD and more to do with just not letting a
paradigm obscure your judgement. In this case TDD helped someone break through
a bit of fog. Not disagreeing, but if that's the case then there should be
additional ways to clear that fog.

~~~
rquantz
I gave you an accidental, fat finger downvote. I am deeply sorry.

------
potatolicious
I currently practice TDD where I work, but this part seems weird to me:

> _" Try not to think of the bigger picture and don’t start create classes you
> think you might need."_

You don't need TDD for this. Even when not doing TDD, if you're dividing your
work up at all, you will naturally achieve this. It's only when you're trying
to build the Golden Gate Bridge in one giant go that you run into situations
where you're over-engineering, over-designing, and over-thinking prematurely.

Divide your problem into subproblems and solve them one at a time, this leads
to a natural growth in complexity and minimizes poorly conceived abstractions.
You don't need TDD for this to be a good idea.

I like TDD, but I dislike how religious it is. Not every problem is best
solved via TDD. It's a tool in your toolbox, not a life philosophy. A strict
adherence to testing has done _wonders_ where I work (and we test iOS apps, no
simple feat in the current ecosystem).

~~~
invalid_arg
> "Not every problem is best solved via TDD."

Totally agree. The result of doing it this way is not always the best
solution. But it was just another way of looking at it that I found
beneficial.

------
rquantz
I'm not sure I understand the hostility towards TDD I sometimes see here. It's
true there are zealots -- people who think just because you've written tests
you will magically automatically have good design, and never have any bugs
ever. But surely there are plenty of reasonable people who recognize there are
trade offs, and find that writing tests first helps them make sure they're
writing the interface they want to, ensures that test coverage is pretty good
even if you don't have the budget/manpower for a whole QA team, and makes it
easier to maintain the code, ultimately, since you'll be alerted to unintended
consequences.

People like the first commenter on the article are even more bewildering. You
have to test your code. Why wouldn't you automate that?

~~~
CJefferson
You see such hostility towards TDD for the same reason you see zealots. In
general (I observe) the stronger some people argue for something, the stronger
others will argue against.

Also, this SMBC comic expresses how I think these things often end up working
out:

[http://www.smbc-comics.com/index.php?db=comics&id=2939](http://www.smbc-
comics.com/index.php?db=comics&id=2939)

------
ed_blackburn
The first comment seems rather harsh. Right tool for the job. TDD invariably
is in my domain, platform and language, but I wouldn't dogmatically insist on
TDD being mandatory for every software system written ever, anywhere.

------
cuttooth
A TDD zealot is the most annoying kind of developer. More at eleven.

~~~
angersock
I know! You try to convince them otherwise, and they get testy.

------
rmcastil
One thing I tell a lot of people who are getting into TDD is to focus on what
you want the class's interface (AKA API) to look like. This means that you can
start with the assertion and work your way backwards.

As the author alludes to this doesn't mean building out the whole
architecture. For me it means just starting out with a simple case, make it
pass, question whether you need to refactor or not and then move onto the next
simplest case. A great example of this is Corey Haine's String Calculator
[https://vimeo.com/7961506](https://vimeo.com/7961506)

I agree that TDD is not for everyone but I've found a lot of it is because
people are either taking too huge of steps or not spending enough time
refactoring their code AND their tests.

In the most ideal world you should have a test suite and when something in
your application breaks you should only have one test that notifies you of
this. This I've found is often very far from the case.

------
ralmeida
I don't do TDD all the time, but I used it in a few strategic projects in
daytime jobs. I was taught TDD in college by an excellent professor that used
a similar approach as the one in the article (write a test, then write the
least code that will pass it, then build from that) and I think it's a healthy
and interesting way to look at TDD.

Another view of TDD that I share is that it can be considered as a spec of
(some strategic parts) of a system written in a programming language, which
makes it unambiguous and - obviously - automatable. I've had good results in
using this approach to introduce TDD to non-technical managers.

I've also found that writing tests for a few corner cases and typical cases
before coding is a good way to make the problem itself (what comes before the
design of the first solution, as the author treats in his article) clearer in
one's head.

------
ceautery
I love the finger-pointing image, it's very "Boy, I'ma tell ya' what..."

~~~
Spearchucker
Agreed!

Also very subjective, in that you're a fan, or not. I've written maybe 10 or
15 tests[1] in my entire career (which formally started in 1989), and have
little use for it.

[1] Testing the water. I saw nothing I liked.

------
contingencies
Link to actual code in the article appears to be down.

~~~
invalid_arg
Here you go. It seems to have gone on holiday

[http://webcache.googleusercontent.com/search?q=cache:QyDYz-s...](http://webcache.googleusercontent.com/search?q=cache:QyDYz-
sGylsJ:butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata+&cd=1&hl=en&ct=clnk&gl=uk)

------
6d0debc071
Same guy further down the blog, which I think gives a fairer presentation of
his position:

 _" TDD is the way to go, I’m absolutely sure of it. It brings more benefits
than you might first think. As well as the simple fact that your code will be
more reliable, it forces you to write your code in a way that is testable,
which in turn will make it loosely coupled and modular. It forces you to think
about what you want your code to do before you start writing it. It brings
other additional benefits that I won’t bother to mention, suffice to say
theres no excuse for not using it in modern development.

[...]

In short unit tests will be more hinderance than help if there is a lot of
prototyping and learning in your application. In cases like this your best
doing away with the tests and just writing the code. Wait until your code
starts to stabilise and then go back and review the situation then.

As much as unit tests give you flexibility by allowing you to change code
quickly with more assurance that you won’t break anything inadvertently. It
can also really slow down prototyping and rapid development if you don’t have
an understanding of your environment.

The reason I mention this is so many tutorials and advice on the internet tell
you to not write a line of code until you’ve written a test. I think you need
to be a little more pragmatic about it."_

[http://mat-mcloughlin.github.io/2013/05/16/when-you-shouldnt...](http://mat-
mcloughlin.github.io/2013/05/16/when-you-shouldnt-test.html)

The problem I have strong advocacy for TDD is the same problem I had for
strong advocacy for OOP, and which the fella above seems to some extent
familiar with: It's good if you don't have a deeper understanding of the
subject but in the long run slavish adherence to a paradigm will cripple your
ability to do things. This is exacerbated by the fact that, in the short run,
you probably won't want to use the tests unless you understand why they'd be
good - and if you understand why they'd be good, then just go ahead and write
the program that way in the first place and save yourself a bunch of time.

The key fact with relation to the original article here is that he didn't see
any of these advantages in TDD until he want to a speech where someone told
him to do TDD another way _and pointed out the advantages._ Which rather
implies that the advantages aren't a result of TDD as much as they are the
result of already knowing something and levering it into a TDD framework...

