Working inwards from the edges of your product is a quick strategy that could provide immediate business value (compared to working from the bottom up watching

Working inwards from the edges of your product is a quick strategy that could provide immediate business value (compared to working from the bottom up watching metrics like coverage) and that means end-to-end testing. Testing the product with end-to-end tests will stop you from shipping a completely broken product to your customer, where the most damage can occur. Add the test script at the end of the build and alert to a dashboard. “Alert” can mean email, and “dashboard” can mean “PC showing inbox for testalerts@mycompany”. You can get that running immediately. Alerts won’t tell you what broke of course, though you can use version control and bisecting to isolate breakages to commits, which is almost as good. When you find bugs, then each bug is an opportunity to put some scaffolding around smaller subsystems as smaller tests to show the actual bug, as well as the fact that the bug has been fixed. Avoid committing the test without committing the fix. It’s a bad habit. You can show how the test used to fail in your commit message. You’ll get an idea as to what are the most problematic pieces of your app. If one part is much less reliable than the others, then you can select that subsystem for verification with bottom up unit tests. Don’t spend too much time on each one though — it’s highly likely that in exercising your APIs through unit testing, you’re going to see ways in which they need to be refactored to make more sense and, importantly, become more reliable.