| A lot of people giving their opinion about TDD, but not many actually answering your question. The answer depends on your approach. You can go outside-in (top-down) or inside-out (bottom-up). The one you use is a matter of taste. A lot of people find outside-in easier, but inside-out can be a bit faster if you have a good sense of how your system will fit together. To take an outside-in approach, start at the top level of your application. Possible just under the UI, because UIs can be hard to test. (If the UI isn’t tested, make it do as little work as possible, and have it just forward to the tested code to do real work.) Test-drive a module, class, or method in that top layer. The smaller the better. If there’s something complicated that should be handled by another module/class/function/method, make the module/function/etc., but just hardcode one answer. Make a note of the things you hardcode. When you’ve finished TDDing your first thing, look at your notes and choose something that you hardcoded. TDD that in the same way. Repeat recursively until the application works. Focus on getting to a working but incomplete application as soon as possible, by working depth-first instead of breadth-first. Once you have a working but incomplete application—a “walking skeleton”—think of a feature you’re missing and add it in the same way. Continue until the application is done. Remember to look for opportunities to improve the design and refactor as you go. Inside-out is very similar, except that you do the depth-first recursion in your head, mentally, and don’t write any code until you get to the leaves of the recursion tree. You test-drive the leaf, then test-drive its caller, etc., until you get to the top. It takes more experience, more thinking about design during TDD, and more willingness to refactor. I have videos on my site if you’d like more. Start with this series: https://www.jamesshore.com/v2/projects/lunch-and-learn |