No one suggests discarding integration tests. The end of the quoted excerpt from Feathers above explicitly supports them. Tests that do these things aren’t bad

No one suggests discarding integration tests. The end of the quoted excerpt from Feathers above explicitly supports them. Tests that do these things aren’t bad. Often they are worth writing, and you generally will write them in unit test harnesses. You hinted at the value of separating unit tests and integration tests with your observation about 40-minute unit test runs being way too slow. The process friction it creates means people will check in “obviously correct” changes without running the tests first. Feathers continues: However, it is important to be able to separate them from true unit tests so that you can keep a set of tests that you can run fast whenever you make changes. You want your unit tests to be an easy habit for a quick sanity check. For the situation you described, I’d suggest moving the integration tests to a separate suite that run at least once a day. Ripping that coverage out of your CI may make you uncomfortable. That’s solid engineering intuition. Let your healthy respect for the likelihood of errors creeping in drive you to add at least one fast (less than one-tenth of a second to run is the rule of thumb from Feathers, p. 13) test in the general area of the slower integration tests. The first one may be challenging to write. From here forward, it will never be easier than today. Putting it off is how your team got to the situation now of having to wait 40 minutes for the green bar. One test is better than no tests. Your first case with the fixture and mocks you create will make adding more fast unit tests easier down the road. Yes, just as it’s possible to make mistakes in production code, it’s certainly possible to make mistakes in test code. Unit tests are sometimes brittle and over-constrain. Refactoring them is fair game too and far better than throwing them away.