Hacker News Reader

Comment by lmm | Hacker News Reader

TDD intentionally encourages a bottom-up programming style where you allow the design to emerge instead of consciously designing up-front. The argument is that this results in better solutions, which in my experience is true - https://wiki.c2.com/?WhatIsAnAdvancer kind of describes the feeling.

View on HN

Yes, I think this is true. While there have to be some big picture strategic design decisions like 'do we use a database or not' and 'is this a server/client application or not' below that very high level it quickly deteriorates into making the big decisions when you have the least information and this leads to decisions that one is probably going to regret.

No. TDD is as top-down as it can be.

« Test-driven development (TDD) is a software development process relying on software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. This is as opposed to software being developed first and test cases created later. » [1]

[1] https://en.m.wikipedia.org/wiki/Test-driven_development

Perhaps it can be both bottom-up and top-down depending on your mindset.

Then it’s not test « driven ».

Then what do you call it where you write programs bottom-up but still write test cases before implementation? Because that's the most common approach that I've seen being done and called TDD.

That's when you adopt other XP practices in addition to TDD.

I call it wasting time trying to fit square pegs in round holes. Many things and approaches have their virtues and their place, be it top-down, bottom-up or tests. Silver bullet techniques and dogma have absolutely none.

Not my experience, shrug.

Yes. TDD is the micro version of Agile. It works because getting adequately comprehensive requirements out of a client, or for a business process, is incredibly hard. The first version will nearly always be significantly wrong. Everyone then shouts "do better", but that's not within your control.

So both Agile and TDD evolve a solution from "in this case, the software needs to do this". You take the software to the client/users, find out the next layer of requirements when they say it's not quite right, and adapt it.

(Every now and again someone tries to make a sort of requirements document that's also an executable test. Directly mapping the given-when-then of user stories to arrange-act-assert. It doesn't work for the usual 5GL reasons, but it doesn't stop people trying)

> TDD intentionally encourages a bottom-up programming style where you allow the design to emerge instead of consciously designing up-front.

In Haskell I do TDD top-down frequently.

How do you TDD before you have anything running end-to-end? Do you do the first chunk of development with only one test? Do you recurse down so you have several layers of failing tests at the start? I don't like either of those options much personally.

Reply on news.ycombinator.com