Timeline for Is it bad practice to code the solution, then redo in TDD?
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 27, 2018 at 15:43 | vote | accept | Maxime Dupré | ||
| Jul 9, 2018 at 2:22 | comment | added | Greg Burghardt | In this case "1. Code the solution" really becomes a proof of concept, which rarely has the same testing requirements as production code. They say the proof is in the pudding --- so make a small batch of pudding first! And if the pudding tastes good, remake it with a TDD approach. Nothing wrong with that. Experiment. | |
| Jul 7, 2018 at 16:01 | comment | added | Stop harming Monica | I have been told that if the book is "Growing OO Software Guided by Tests" then top-down TDD is well covered. I have not read that book myself but the approach is actually quite common. Your first tests specify how the system interacts with the outside world in the simplest possible terms. All the upfront design you need is specifying an input / event and an output / side effect and that goes straight into the test. As you add tests with more details you start to split the system into components and give them different responsibilities. | |
| Jul 7, 2018 at 15:07 | comment | added | svidgen | I don't think I agree with this. I've TDD'd top down... As far as I'm concerned, your driving tests don't need to start with small-unit tests. You can have an integration or big-unit test driving interface design and other tests. | |
| Jul 7, 2018 at 5:02 | history | edited | Doc Brown | CC BY-SA 4.0 | added 1 character in body |
| Jul 7, 2018 at 4:51 | history | edited | Doc Brown | CC BY-SA 4.0 | added 390 characters in body |
| Jul 7, 2018 at 4:43 | history | answered | Doc Brown | CC BY-SA 4.0 |