Forcing yourself to not write a line of production code without having a test in place to test it first produces a very high level of coverage over all your con

Forcing yourself to not write a line of production code without having a test in place to test it first produces a very high level of coverage over all your control paths. You wind up with the tests being an ad hoc specification for the production code. Not really a design as much as documenting the code. This is a really irksome way for me to work, and I find that level of diligence difficult to muster. Often I will find myself writing the production code first and writing tests to cover after the fact. My coverage is probably not as high as it is when I TDD the code. The cadence of TDD'd projects I've worked on professionally is painfully slow and predictable. If you're at a workplace that is giving you the time and resources to do it, then you're likely also pairing, which helps impatient souls like me stick to the program. My team has been blessed to have a devops guy who has a scientific mind and acts as informal agile coach while pairing - and he's probably the reason we do a good job on the TDD because he makes us all better at it. If you're at a workplace that is encouraging TDD and pairing, you should be thankful and honestly try to do a great job at it. Your work weeks will be relaxed and you probably won't need to work much overtime. I wind up with lots of left over energy to burn on my home projects, which I appreciate.