Ask HN: Do you follow TDD at work?

First and foremost, I does not treat anything as gospel. TDD, like everythingthing else, might not make sense in all scenarios.<p>I often use TDD for microservices. It forces me to define REST service interface from the perspective of consumers, and only then jump into implementing it. So I write tests that call the service for various use cases, and asserts for returned status code, pay load, and any invariances. All tests fail initially.<p>It is indeed cumbersome, requires disipline, but it becomes easier with practice. I find, it particularly useful for for microservices. Earlier I would implement, then test, and while doing both will keep figuring a better API and keep changing. With TDD, I upfront get the clarity what functionality I want to implement, so counterintuitively TDD makes me faster.<p>I use it mostly wherever interfaces are involved. For example, if my service is using a DB, unless the use cases are too simple, I write tests for that API.<p>Parts that does not have (external) interface, and I want it to be fluid&#x2F;evolve, I write tests only after implementing. But service level (TDD) tests provide some safety net.<p>I can see this approach can be extended at all levels, but I am not sure about costs vs. benefits tradeoffs. I think if I do TDD only for macro (process&#x2F;service&#x2F;subsystem interfaces kind of things) and some leaf library type modules, tradeoffs are favourable. And if you have TDD for those, the returns of doing it for rest diminish.<p>Disclaimer: I haven&#x27;t done detailed study, I am telling my experience, so only one data point.

In the real world, most people don&#x27;t do TDD at work.<p>In my opinion it&#x27;s a good tool in some cases, for simple algorithms or when you know exactly what you want. But most of the time it&#x27;s too cumbersome or totally not practical. So you should not force yourself to do TDD for the sake of it. That&#x27;s also why you only find toys examples, where TDD is a good idea for them.

How do you know what to code if you are not clear about the code&#x27;s expected behaviour?<p>This is one of the principles of TDD: be clear about what your code should do (i.e. it&#x27;s behaviour) before you start coding.