41–50 of 86 posts
There are tons of books about the subject. Can tell us which you already read?
Now the only problem I have with TDD is time. It takes a lot of time to do it right and usually I don't have that time (in my organisation). So maybe you can tdd some parts of your application, maybe the most critical parts. Even for personal projects you may not have the time: demotivation usually kicks in for personal projects. TDD defers results and the positive feedback needed to keep going. At least in my experience
Now what does work is if you can decompose the whole idea into parts, each of which is written using TDD. You might still want to outline some key interfaces so you get the shapes of things to fit. With practice, all this extra stuff often happens in your head as you're doing TDD and you make adjustments along the way.
Also, the way you described making bottom-up things that didn't quite work, is a valid and possibly effective way of doing TDD. If you're able to determine that a lower implementation is unsuitable it can be rewritten and if the tests are not too brittle will give you confidence to do the rewrite safely and faster.
I’ve found it safer to start with (manual) integration tests where I verify intended behavior from outside in. That avoids building inner layers which turn out to be slightly but annoyingly off compared to what is desired.
Unfortunately, as soon as you jump off the pure OO bits and domain logic, the TDD-ness of your end-to-end program could be all over the place. You’re entirely at the mercy of available tools and your proficiency with them, and the time you can invest in learning those tools.
There are tons of books about the subject. Can tell us which you already read?
Only Kent Beck’s one, but honestly I might need to revisit it (I only vaguely remember how he approached the two examples on the book). If you have other suggestions of books you found insightful please let me know. Thanks!
Don't think in terms of tests -- think in terms of examples. Write examples of how you would like to be able to solve common cases and handle edge cases if you had the ideal interface based on what you know at the time, then use unit tests with stubbed out interfaces as a tool while trying to develop the implementation. Refine and even rewrite your examples as you learn about what works and what doesn't work. Recursi…
Earlier quoted context omitted.
Seconded. Only ever add tests after you have a working version. Starting a greenfield project with TDD is a waste of time. Just get something out then start testing your assumptions with unit tests, even then, don't test the whole codebase, test your fundamental assumptions and core features (like user auth, roles, permissions and their invocations, esp if multi-tenanted).
The way to do it using TDD is to do your greenfield development to the point of a working solution to elicit your fine-grained requirements, then throw that away and rewrite it using TDD. The first version is considered a "spike solution" and is not supposed to touch production. In TDD, all production code must be written against some pre-existing test. Any code which does not meet this criterion is broken.
Read about AMDD. The idea is: you not only write tests to design and iterate on that, but also sketch a model of your system and iterate that. Depending on the size you may want to sketch subsystems, etc. Now the only problem I have with TDD is time. It takes a lot of time to do it right and usually I don't have that time (in my organisation). So maybe you can tdd some parts of your application, maybe the most critic…
I'm not quite getting your categorization of the first approach as top-down and second as bottom-up, they are the opposite to me. Your program is going to have a flow like this: $ rcd2-awesome-finance-app september2022.csv Category Amount Food $100.00 Clothes $200.00 ... Internally it'll be like this: main(string filename) csv = open(filename) cat->$ = new dict() foreach line in csv transaction = parse(line) cat = ca…