Software Testing Anti-patterns
&gt;&gt; Anti-Pattern 2 - Having integration tests without unit tests<p>I strongly disagree with this one. I think that unit tests only make sense when the project&#x27;s code has really settled down (not likely to change in the future) and you want to lock it down to prevent new developers on the team from accidentally breaking things.<p>Unit tests severely slow down development. I&#x27;ve worked on projects where it takes 2 to 3 days to update a single property on a JSON object on a REST API endpoint because changing a single property means that you have to update a ton of unit tests. The cons of unit testing are:<p>- It locks down your code, so if your code is not structurally perfect (which it definitely is not for most of the project&#x27;s life-cycle) then you will have to keep updating the tests as you write more code and more functions around.<p>- It encourages you to use certain patterns like dependency injection which might make sense for some (e.g. statically typed) programming languages but are unsuitable for other (e.g. dynamically typed) languages because they make it difficult to track down dependencies.<p>- It only makes sense for parts of the project that have strict reliability requirements and where any downtime&#x2F;failure in that part of the code would result in some loss of business. It&#x27;s important not to underestimate the maintenance cost of unit tests. More unit tests means much slower development (cuts productivity to half or sometimes even a quarter of what it was without tests for small teams), which means that you need to hire many times more developers to get the same productivity that you could get from a single developer. Sometimes it&#x27;s OK if a part of the code breaks in non-critical parts of the system; especially if you have some kind of user-feedback system in place.