Ask HN: Seriously, how do you TDD?

There is a lot of really good advices here about when to do TDD and how to do it, so i would only reiterate earlier comments.

My personal experience is that i start TDD once my project is "mature" enough that the next upgrade/addition can be put at two different place easily enough and i don't know where is the best place to do it. Basically, on my latest project, i asked myself something like: "is this part of this class method, or should the main loop take care of it?". That's where i started completing tests to 90% coverage (main loop + pagination mocks were skipped, ideally i could've reach 95% but laziness caught up) and started TDD. In the end, i still made the wrong choice and added my change to the class method, only to change it back two weeks ago (or roughly six month later). Here, TDD didn't help me to make the best software architecture choice, but having to write test first for this part of code made me decouple it from the method i originally put it in, and allowed me to made a architecture change in less than an hour.

A very good explanation. Yet what I think is confusing a lot of (very?) good programmers (not me) is that they already do that intuitively by not letting methods become longer than 3 or 4 lines, and whenever implementing a new method, by writing the return statement first (i.e. returning a mock object or similar) and working backwards, i.e. only writing enough code to be able to return the desired value.

If one then goes and tries to write tests for these kind of methods, it feels like superfluous busywork.

A year into a novel project, a teammate expressed their concern about a lack of unit tests. They'd even spent time creating a bunch early on. I asked if they still ran or were even relevant any longer and the answer was no.

Particularly with exploratory projects, I'd recommend focusing on rapidly iterating to reach the simplest solution (businesswise and implementation-wise).

If in the end non-trivial logic must be specified, write some tests. Your definition of 'non-trivial' will change with experience.

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).

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.

Recursively break down complex pieces into smaller modules as you learn what can be handled independently and composed with the other pieces. Break off independent examples depicting how you expect those modules to work and be used as new unit test suites for those new modules.

Don't sweat testing the implementation details, especially when prototyping. What you want is to use tests as a way to speed up your development process and improve the quality of your design and architecture.

Try to write tests that show off how nice your code is to use and how few edge cases you need to handle when calling it. It'll raise the bar for how your code interacts with the rest of the application or system and give you smaller pieces to work and focus on.

Finally, for really green field stuff with a lot of unknown unknowns, you often have to write a lot of standalone, bottom-up throw-away prototypes for things. That doesn't invalidate the usefulness of tests, so don't be afraid to do that pretty regularly.