Lean Testing or Why Unit Tests Are Worse Than You Think
Integration testing and unit testing aren&#x27;t direct substitutes.  You would never ever say &quot;I have unit tests, I don&#x27;t need to run the product before shipping it&quot;.  Furthermore, automated integration testing is strictly less capable than a human doing integration testing.<p>Unit tests also have the advantage of being cheap to set up and cheap to run, so their limitations in whole-system testing are offset by the fact that you can have many, many more of them.  You can easily blow through a couple thousand unit tests in a matter of 10 minutes or less, whereas even a modest battery of integration testing will be an overnight process at best.  That means your OODA loop is a lot faster on unit testing.<p>(the ideal is of course structuring your application so you can deploy many tests in parallel, but that&#x27;s not always possible.)<p>Fixing Selenium so WebDriver instances don&#x27;t take 60+ seconds to launch would be a major help.  Until then, integration tests that work at a controller level (minus the UI) are probably the best compromise between speed and integration.  You can pass in a mocked request as input, and assert on the output.  Runs much faster than a &quot;true&quot; integration test with a driven browser client, but hits the whole stack better than a unit test.  They are also really easy to set up, since you can just have a tester or an integration test go through the motions and then dump request data to JSON, then feed it back as a test.  The lack of state persisted between requests makes implementation a lot simpler.