I've absolutely built projects without tests, let alone without TDD. They eventually became overloaded with tech debt. That said, the wrong types of tests can b

I've absolutely built projects without tests, let alone without TDD. They eventually became overloaded with tech debt. That said, the wrong types of tests can become a straitjacket instead of a support system. I don't particularly enjoy TDD, where you write the tests first. I do enjoy what I call test-oriented development, where code doesn't get merged without tests, and automated testing is how you verify any changes before committing them (though for UI and workflows you should always have an acceptance testing stage). It goes a long way towards making me feel confident in my code; it gives me a structured point in my workflow to consider what the edge and corner cases might be and how to deal with them; and it often helps me catch and verify fixes for subtle (or not so subtle) bugs much sooner and with a lot less effort than click-throughs would. Edited to add: you say you spend a lot of time mocking databases and such. I usually plan to have a DB available for testing. Django in particular makes this easy by building an empty DB scheme for each test run and running every test in a transaction that gets rolled back so that the DB is in a known state for the next test. Some things you may just want to use instead of mocking, especially if they don't require running an additional process (sockets seem like an example of that to me, depending on what you're doing with them). For other interfaces (especially third-party web APIs), look for libraries in your language that will let you mock requests, specifying responses. If there isn't one, build one for re-use, use it for all your projects, and release it open-source. That'd be a great way to earn some visibility in your ecosystem.