Comment by mikekchar | Hacker News Reader

Comment by mikekchar | Hacker News Reader

Parent Full thread

Here's a question I find interesting, though: Do you TDD or do you write tests? Lots of people write tests for their code. I don't know many people who actively embrace the idea of TDD -- where the testing activity is driving the other aspects of their coding. Even among the people who do, I know of very few people who agree on what the word "driven" means. I suppose I should be more inclusive and say that "driven" might just mean, "I write tests". I've had numerous people tell me that it is improper when doing TDD to modify production code to suit your tests (which, for me is a really weird definition of the word "driven" ;-) ).

If you do TDD, how do your tests drive your development and do you find that it is a concept that you are able to communicate to others easily?

Disclaimer: I have not listened to the podcast, but the combination of the title and this comment was too thought provoking to let slip by :-) Now I'm quite excited to find some time to listen to the podcast!

What I've found most people do wrong is start with unit tests, which test implementation not deliverable, then realize after writing a bunch of code they did it wrong.

I tend to write the acceptance test first.

e.g. #1 If I'm writing a web app I write a selenium test "as a user, when I click the button, I see X".

e.g. #2 If I'm writing a distributed database, I write a test "state should converge".

These acceptance tests (aka end-to-end, UAT, UI test) ensure the desired end state is tested for, then I work outside-in to create implementation, writing unit tests as needed along the way.

When I find people fail at TDD, it's usually due to the lack of knowledge, ability or infrastructure to approach the problem this way.

Small stories in the correct order are also critical. I agree with the "risk first" approach an article on HN described yesterday.

Source: I taught a course on TDD to some big enterprise clients.

Regarding your first paragraph. It sounds like your mixing up the TDD workflow with ATDD. ATDD uses a requirements level view (macro test) and those concepts are usually well known before starting development. So you can write those tests upfront before development.

TDD is about writing tests as you build the design. You’re not supposed to write a bunch of micro tests before writing any code. Rather you want to write a single micro test, then write a little code, when the test goes from red to green, you then enhance your existing test or add another test, then add a little more product code. So the effect is growing your tests as you grow your product code. Episode 12 illustrates this workflow for a simple example: https://agilenoir.biz/podcast/012-an-example-of-doing-tdd/

The TDD series starts with episode 9 and is still continuing as of episode 15. https://agilenoir.biz/series/agile-thoughts/

The problem I find is that it takes quite a long time after having a sketch solution to realize that it’s a dead end.

You start with “as a user when I press the X button...” but you realize there is no way a button will do. The premise is flawed. It has to be a multiselect list. And this can’t be a user thing, it has to be a config thing” and so on. That is: you can’t (no one could) even specify what is to be implemented without implementing one or more sketch solutions. You can specify the user problem but not the solution. “as a user I need to do X”. But a problem specification alone doesn’t allow easily creating a test on any level.

If I were to do “TDD” I’d perhaps accept tests as being not the first step but the step before the final solution. Sketch solution(s). Throw away sketch. Tests. Final solution.

> Sketch solution(s). Throw away sketch. Tests. Final solution.

I think it's worth pointing out that this has been my interpretation of the general approach that XP originally took many years ago. If you know the general design that your story should take, you do a test first approach using your knowledge of what you are doing as a guide. However, if you don't have a good idea of the best approach to take, you "spike" a solution, throw away the code and then use test first to develop the "final" solution (hard to say "final solution" in XP, so I hope people understand what I'm saying here -- the solution that will be refactored over time as opposed to the solution that will be rewritten ;-) ). As the sibling thread pointed out, though, "test first" in the TDD sense is an iterative process and usually you write a test, satisfy it, write another test, etc, etc. You wouldn't want to write all your tests up front because it would constrain your design too much -- and then it wouldn't be "test driven", even if it is good ;-).

I find it especially interesting that you use the word "sketch", which is exactly the same word I use. For me the activity is based around trying to get my head around the basic composition in the design. But like you say, if you are unsure about the UX workflow, just banging out some code and looking at it can make you realise, "That work flow is just not going to cut it because it doesn't use/generate the information I need".

Reply on news.ycombinator.com