The observation about the focus on unit tests is well-made. I think it's a crucial problem that stems from very good tools for unit testing and developers that

The observation about the focus on unit tests is well-made. I think it's a crucial problem that stems from very good tools for unit testing and developers that are very familiar with these tools. It's then very simple to discard anything that isn't covered by these great tools. But here's an anecdote that explains why you'd always want integration tests (other anecdotes for other test paradigms probably also exist): imagine a modern subway train. That train is highly automated but, for safety reasons, still requires a driver. The train has two important safety features: 1. The train won't leave a station unless the driver gives their OK. 2. The train won't leave the station unless all doors are closed. The following happened during testing: The driver gives the OK to leave the station. The train doesn't start because a door is still open. The driver leaves the train and finds one door blocked. After the driver removes the blockage the door closes and the train departs. Now driverless. I think it's crucial to view integration tests as unit tests on a different level: You need to test services, programs, and subsystems as well as your classes, methods, or modules.