
How I reliably enter the Zone: TDD - akkartik
http://en.heavyelectrons.com/posts/hackers-how-to-enter-the-zone-at-will/
======
ardit33
There is another way better way. Program to interfaces. Or write out all the
methods you need, have empty bodies, and implement them one by one. From the
lower level/helpers, to the higher level ones. If any method becomes too
large, or if there is a lot of redundancy, break it in smaller units.

I think TDD hampers design, as it places a penalty on every time you want to
reactor code while you are still implementing it and it keeps you vested on
current code, which is against the "keep it simple, and easy to change"
principle. In languages like java, it may force you to break encapsulation and
good design, just to have your code tested. (how many times have you see this
comment: "don't use this, just for testing purposes") in side of methods.

If you must do testing, a functional level testing is much better. Where you
test only the higher level methods that have are acting on the functionality,
but don't care about the lower level/helper methods.

Take the holistic approach, and don't sweat the details. If you do a good job
on breaking the implementation in small/reasonable sized methods, then it is
easy to spot errors when you are developing. Try the best to avoid methods
with side effects (modifying shared resources), and keep the methods dumb:
input in, input out, no side effects.. Just test the one method that is being
called for that particular functionality, and if everything is working well,
your overall test should come out as positive.

What I really hate is mandatory: "you must cover 90% of your code with unit
tests" type of orders by CTO/VP engineering types.

~~~
abdulhaq
> "you must cover 90% of your code with unit tests"

No, TDD doesn't mean that. TDD is where you write the tests _first_. This
bestows numerous advantages that post-facto tests don't:

1) You think about the API as required by the person using the interface that
you are coding up.

2) - and this is the killer - you are forced to create repeatable test data
and fixtures (e.g. in memory sql databases a la sqlite). As the functionality
and number of services builds up, you create, whether you like it or not, a
large suite of easily instantiated, complex mock services that allow you to
build truly automated and repeatable high level tests.

3) And you can then safely refactor much more reliably and confidently when
features and ideas have changed.

I agree that writing tests after the fact is a waste of time. TDD saves time
(and hair!).

~~~
gaius
TDD is a brute-force method for evading the need to understand side-effects. I
consider situations in which TDD applies to be warning signs, not
opportunities.

~~~
eru
Side-effects are evil [1] and it's good that TDD encourages you to minimize
side-effects.

[1] That's one reason why functional programming raises productivity.

------
DenisM
FWIW a book recommendation from articles comments:

[http://www.amazon.com/Test-Driven-Development-Addison-
Wesley...](http://www.amazon.com/Test-Driven-Development-Addison-Wesley-
Signature/dp/0321146530)

------
Tichy
tdd = test driven design

------
DanielBMarkham
I'm an agile coach, so I'm supposed to support TDD.

But I just don't get it. I think you should unit test as you code, sure (for
big things), but testing as a design strategy? As a way of "getting into the
zone"?

I'm glad this guy seems excited about it. I'm trying to collect examples of
people who actually use it out of their own choice. I think this is number 4
from the last six months.

Nobody wants to be behind the curve -- maybe TDD is the next evolution in
programming styles. Or maybe it's just a reaction against heavy-handed,
overdone design by architects. Or maybe a little of each.

The jury is still out with me.

~~~
akkartik
I'm not sure how well TDD works in the large, but for one man on small
projects it's great. It's not substituting for design or anything. It's
keeping me from getting stuck in a rut. But it's possible it's not so much TDD
as just the process of managing stories. If that helps understand where I'm
coming from.

~~~
DanielBMarkham
From what I can see (and I've read up a bit and worked with some of the big
guys in the field) TDD is a "small shop" kind of philosophy. I would think it
would work best in teams of 1-4 developers. 4 or over, however, and it seems
like it would fall apart. People factor out code in different ways -- for
instance, some naturally lean towards functional code while others lean toward
imperative code. In modern languages, you can use both. Some folks love
interfaces while others won't stand for a public variable. How code "smells"
(and I hate that term) looks to me like it can vary a whole lot depending on
the programmer. So in larger teams, you can't have 10 different versions of
code re-factoring. You have to expect some consistency. There is a place for
group decisions. Some team-level thinking ahead makes sense.

But on a 1 or 2 person team? That looks like a completely different animal.

What we're finding, however (as consultants), is that companies are getting
sold on lightweight technologies that work great at the small team level and
then don't work so hot with fifty thousand developers. It's complex.

Thanks for the feedback. HappyTDDCoderCount++

~~~
akkartik
Are these fifty thousand developers on a new codebase? Bolting TDD onto legacy
software (<http://akkartik.name/blog/4664263>) is hard, but that's perhaps
different from saying TDD doesn't 'scale'.

~~~
DanielBMarkham
I must be misunderstanding something. I was expressing concern that it can
scale _due to the size of the development team_. New or old codebases have
little to do with. I'm fully aware that TDD works with legacy code.

I'm in a learning mode, however. I'm trying to gather all of the data
possible. And by data, I mean real, live, large teams who not only use TDD but
do so gladly and would never go back to the old ways. Not consultants,
authors, teachers, methodologists, coaches, or anybody else who isn't
developing code. We've got enough of that already in the biz.

In my small world I haven't come across those teams yet. I think several
examples along those lines would do the most to show me that TDD was worth
picking up both as a personal and as a coaching practice.

Having said that, in some ways we may be parsing words. I design in a
lightweight fashion top-down and then code and refactor bottom-up, unit
testing as I go. In some ways, this IS TDD, except that I'm not using the
test-first mantra as a design crutch. I already know how to design.

~~~
akkartik
I didn't mean to sound critical. I don't really have any experience with large
teams. Let me try to rephrase.

A large team would probably imply a large codebase, so are you aware of
attempts to separate those two variables? For example it's interesting to me
that attempts to do TDD on large codebases have met with success.

Your response also raised another interesting question. TDD could be hard to
scale with team size because of intrinsic issues or just the difficulty in
'infecting' a large group with it. I wonder which is larger part of the
reason.

