I like TDD but it should be adapted to the project. For some projects, I only do integration tests, for others, I only write the unit tests for one or a few of

I like TDD but it should be adapted to the project. For some projects, I only do integration tests, for others, I only write the unit tests for one or a few of the more complex modules and test the whole system manually then if needed I will add more tests later after the project code has settled. It depends on a lot of things; such as what kind of complexity the project's modules are prone to (algorithmic complexity or integration complexity), team size, security requirements and reliability requirements. It's very important to keep the testing as minimal as possible at the beginning. Sometimes minimal means a lot, but you need to be able to justify it because tests (especially unit tests) lock down interfaces and functionality and this can go against agile principles. If your project is innovative and requires that agility. After 15 years experience coding on many different projects and companies, what I learned is that blanket statements are often unhelpful. You need to critically evaluate every case as unique and make arguments about why and how your case differs from the norm (and it usually does).