4 ms·

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

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.

lancerkind 8y ago
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/ 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/ https://agilenoir.biz/series/agile-thoughts/
alkonaut 8y ago
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.
- mikekchar 8y ago
  > 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".

lancerkind 8y ago

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/ 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/ https://agilenoir.biz/series/agile-thoughts/

alkonaut 8y ago

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.

mikekchar 8y ago
> 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".