It’s right there in the name TDD. You write a test and then you change the code to make the test pass. There are no secrets, that’s all there is to it. If you c

It’s right there in the name TDD. You write a test and then you change the code to make the test pass. There are no secrets, that’s all there is to it. If you can do that you can do TDD. That’s why everyone else is putting it on their CV and you aren’t: you think there’s something more to it. There isn’t. It’s a very basic technique. > how to write code so that it can be proven it works the way intended and that it can handle unhappy paths and edge cases That is not what TDD promises. All TDD does is ensure you have some tests at all, which is a good base on which to add more tests, so that when you find edge cases you can do more TDD, and TDD is a nice way to work. Nobody in history has come up with a way to make testing comprehensive. You can try quickcheck and fuzzing to generate lots and lots of test cases, but they are still sampling from the input space rather than covering it. You can cover the input space for a single 32-bit number input, but that’s about it. The only way to do better is to formally prove your software is correct using mathematical logic. TDD does not provide this and never will. You might have seen “100% test coverage”, but that claim is close to meaningless with respect to the range of possible inputs that your code is meant to handle. All it says is that every edge case that you did think of has a test that exercises it. A function consisting of “return 0” only will have 100% test coverage with a single test in the suite. Doesn’t mean it works. See SQLite, which still finds bugs despite 100% test coverage. What you seem to be looking for is someone to teach you how to think of edge cases. That’s a skill that can’t really be taught. Just have a go. When you find an edge case later that you didn’t think of, great, maybe you will think of similar ones next time.