Hacker News Reader

Comment by jpz | Hacker News Reader

TDD for a complex domain generally means (at least in an OO design) you cannot do exploratory coding over what objects you have and what decisions you will make.

After all, you have to write the tests for the classes, before the classes exist.

When you do so, then start to fill in the code, and then realise you need to refactor, you have a heap of tests you need to refactor. It always appeared to me highly inefficient and predicated on an assumption that the author can express his class heirarchies well ahead of the coding.

In my experience, the class design is highly iterative, even the names of methods, what methods you have, etc - to have to write the tests before you've written the code just creates a huge amount of impediments to the flow of expressing a solution.

This is not a criticism of unit testing - but of TDD.

View on HN

In the version of TDD I've been exposed to, you only write the minimum number of tests to cover your next feature. It's still iterative.

I do more TDD on exploratory work than something fully formed because I can work in a narrow scope without having to grasp the whole project.

If you only know what the feature is, you're prepared to write functional and/or integration tests, but not unit tests. Unit tests closely wrap the details of the implementation.

An important requirement of TDD is that you decouple the functionality from the implementation, for exactly this reason. You should be able to completely rewrite your implementation from scratch, and only minimally update your tests. And the ability to do that is exactly the benefit that TDD can bring.

I find red-green-refactor MOST helpful during exploratory coding. There's a principle that Uncle Bob calls "Don't go for the gold": "stay away from the center of the algorithm for as long as possible. Deal with the degenerate, trivial, and simple administrative tasks first." I build up to the final, complex final functionality one small step at a time. At no point do I need to architect the whole kit and caboodle at once, then re-architect, then re-architect. It's all just aggregate improvements and refactoring what's already there.

Your quotes from Uncle Bob to my ears sound like trite nonsense. Moreover, name-checking him and then giving quotations of what he said seems positively religious.

My basic argument with agile is this - can it be measured that these things are good? Or is it just a pile of piffle built on anecdotal evidence - that people get paid thousands of dollars a day as consultants to espouse?

The industry has a long legacy of this - e.g. designing your classes in UML will solve your problems, or the Rational Unified Process, or prior to that, in the early 90s, Rational Rose diagramming experience was the "must have" on your CV.

One of the more reasonable analysis tools was Use Cases in my view, but most of it is just a bunch of noise, busy-making tasks which Andersen Consulting were more than happy to provide 100 people doing these tasks and bilk some client 100m for the pleasure.

There's no substitute for high quality, intelligent people self-organising. People that want to proceduralise developer behaviour are basically people that want to steal our freedom to be creative and effective, in the manner which befits ourselves as individuals. And make themselves ghastly rich doing it.

I don't see Uncle Bob as all that different, having hung out in the Agile evangelist scene in London for a while - they are all on the lam.

In my opinion.

My experience as well. There is usually not enough information available to write truly useful tests at the point TDD wants you to.

TDD is meant to be done on public interfaces. So TDD is meant to allow you design interfaces from the pov of a consumer of that public interfaces.

This is high falutin’ theory.

Many user interfaces don’t have easily testable abstract interfaces, and user features are first tackled by expressing changes to a user interface.

You really have to jump through hoops to make the reality of coding meet the theoretical model.

We're not talking about user interfaces. It's what the user interface calls.

Reply on news.ycombinator.com