

Things I learnt by not writing tests - transmit101
http://rfw.posterous.com/things-i-learnt-by-not-writing-tests

======
abstractbill
_Firstly, writing test-first permanently changed the way I write code ....
They still tend to be short, descriptive and as self-contained as I can make
them, and as a result easier to understand and change_

I learned exactly the same lessons from writing code in a functional style.
The experience changed my style for the better, and that carries over even
when I'm using a language that doesn't lend itself very well to functional
programming.

------
richcollins
I'll give my usual critique of religious TDD:

Most of the features I develop aren't good ideas in the end. Writing a test
for a feature that you are going to dump after testing it with actual users is
a waste of time.

Once a feature has proven its worth, I write tests to protect its value.

~~~
Vitaly
the problem with your argument is the hidden assumption that writing tests
wastes time, when in practice it usually saves it. Long term benefit of tests
is rarely denied, but as many of the TDD people can tell it usually saves time
even in short term. when you develop a feature _you_ are testing it, manually,
by refreshing your browser and sometimes performing non-trivial sequences with
it. Writing tests to do just that can save you time and leaves you with a
better code.

------
jordyhoyt
I completely agree about the power of test-driven development, but I think the
take-away hits home the most:

"...shaking things up, doing things a different way for awhile..., is never a
bad idea."

I recently spent some time forcing a friend of mine to learn some basic Scheme
(which I learned in school, and have always loved), to try his hand at
programming. This led to basically reading though my Scheme book again and
hacking through some examples. Going back to work - developing in Java - I
found myself writing much more concise code and spending enough time thinking
about the problem to find a solution that felt elegant.

Edit: I'd add to the article's point by saying: don't stay in the same
environment for too long, or you'll get stale. Switch things up from time to
time, even if that means switching to an environment that is inferior in some
ways - you'll get something out of it.

------
herdrick
" _Secondly, I've realised that when I don't write tests I code too fast._ "
Excellent inadvertent criticism of TDD. Thanks for the post.

~~~
tentonova2
I'm not religiously in favor of "tests first, always" (who _actually_ is?),
but I find that when you emphasize testing, you spend less time debugging,
more time coding, and the end result is generally better engineered.

After over a decade of writing software, I'm willing to accept this up-front
cost in favor of long-term (and often short-term) gain. Sure, I can quickly
hack out code when I'm not writing tests, but long term experience with both
methodologies has demonstrated to me that _it's not worth it._

~~~
silentbicycle
> who actually is?

Like many other 'methodologies', it has uncritical advocacy.
([http://blog.objectmentor.com/articles/2009/10/07/tdd-
derange...](http://blog.objectmentor.com/articles/2009/10/07/tdd-derangement-
syndrome)) (HN discussion: <http://news.ycombinator.com/item?id=866707>)

I agree that automatic testing is nearly always a net gain, but using tests
themselves _as the primary driver for the design process_ suggests to me that
the developer has little other design experience to draw upon.

------
messel
One thing that discouraged me "Test-driven development is difficult to use in
situations where full functional tests are required to determine success or
failure. Examples of these are user interfaces, programs that work with
databases, and some that depend on specific network configurations. TDD
encourages developers to put the minimum amount of code into such modules and
to maximise the logic that is in testable library code, using fakes and mocks
to represent the outside world."

A good portion of interconnected web apps are API calls, and database
updates/queries. For the type of programming I'm learning/doing now (web
programming in ruby on rails), the tests are never sufficient to test
anything. I fire up a browser and get a user eye view of what's happening
while looking at the log. Maybe that's old school thinking but it's working
well for us as this point.

Would appreciate any tips to help us be more efficient of course
(victusmedia.com)

~~~
jdminhbg
I had the same issue with TDD in Rails, where my functional tests were so
brittle that they took more work than they saved, and my unit tests were so
simple that I wasn't getting anything useful out of it.

What I really wanted to know was "will my site work," and I found
Cucumber+Webrat to be an efficient way of being sure of that. I TDD Cucumber
scenarios now, and it makes me more confident without feeling like I'm
spending all my time fighting with a testing framework.

------
lyudmil
I use TDD on all my projects. I also regard myself as extremely pragmatic in
my work. If I felt I would do better without designing test-first I would not
be doing it (on some projects I have less-than-full coverage because it felt
like the investment was not worth it). On to my point...

One thing that always frustrates me in these debates is all the hypothesizing
people who are skeptical of TDD do about what it would mean if they were to
use it. For example:

"For the type of programming I'm learning/doing now (web programming in ruby
on rails), the tests are never sufficient to test anything."

RoR is specifically built to make test-driven web development easy. I'm not
saying the poster is wrong not to use TDD on their project, just that
statements like that should not be taken at face value. It is clear that at
least for some people doing certain types of work TDD is a big help. That's an
indisputable fact. Therefore, the only reasonable positions one might hold are
the following:

1) I agree with these people. TDD is great and I use it all the time. 2) I
don't want to use TDD. It just does not match the way I think about my work. I
choose not to use it, but I do not claim to know why using it is a bad idea.
3) I tried TDD and mastered it. Anyone well-versed in TDD would confirm that I
can do it "the right way". I found the following problems in my test-driven
code: ... For those reasons I would recommend that people stay away.

I think any other position would be disingenuous or lazy. Also note that only
opinion 3 is in any way interesting to read about. It kind of feels like
unless you're making that claim there is no useful way to comment on the
utility of TDD.

~~~
DanielBMarkham
I find your logic interesting.

So let's say I have this new way of doing things. It's called "hit your head
with a hammer". I'm crazy about it and wrote a bunch of books about it. Other
people have tried hitting their head with a hammer and, although there are
many detractors, there are also some big fans.

So what you're saying is: we cannot make a legitimate (or "interesting")
observation about "hit yourself in the head with a hammer" unless we also have
mastered the art of doing it. Only then would we have something worthwhile to
add.

I'm not saying TDD is bad. What I'm saying is that it's perfectly fine to look
at the phenomenon from the outside and make general observations about it. For
instance, "TDD is very hard to impose on most teams" or "When implementing TDD
for the first time, teams experience a significant drop in performance"

I'm sure there are lots of others.

Uncle Bob (and others) have made a mockery out of informed discussion in
regards to TDD. Here's hoping we can keep a reasoned and civilized discussion
going in the community.

~~~
lyudmil
I agree. I would say the observations you give as examples are backed by
evidence and thus interesting to read (and, in fact, legitimate). I stated my
case badly, but I would include such statements in the third category. I meant
what I said to be a call for civilized discussion about the topic which echoes
your sentiment. I also wanted to point out that such discussions have an
annoyingly low signal-to-noise ratio.

[Edit] I also was not trying to suggest a general strategy for evaluating
programming practices. I made the assertion it was clear TDD has value at
least in certain contexts. In the case of TDD I think it is evident its
benefits are subtle enough to approach the issue more carefully.

------
bliss
Why not test rails apps?? That's the bit I don't get... for starters get a
hold of sahi <http://sahi.co.in/w/> (other web test tools also exist...).
Voila simple tdd in the browser environment.

In defence of the article, tdd is something i do in my head but rarely to the
nth degree in practice. I'm more of a fdd kind of person, but I think that
there are a lot of parallels with the two approaches.

------
icefox
In a similar vain to what the author is talking about by writing tests you
probably end up creating a better api, especially if you write the tests
first.

~~~
silentbicycle
Well, sure. Designing an API, informed by feedback from writing some tests as
you go, and dogmatically insisting that it's best to always write tests first
and _let that be the primary driver of the design process_ are two different
things, however. (Not implying that you're saying the latter.)

I don't think a lot of people would argue that writing tests can be a good way
to get feedback about a design. Some particularly vocal TDD advocates seem to
be making it into an all-or-nothing issue, though.

