I think the fact that tests break is totally fine. You should expect them to break if your application changes. What you need however is a short feedback loop.

I think the fact that tests break is totally fine. You should expect them to break if your application changes. What you need however is a short feedback loop. We use a combination of unit-tests for the things that are straight-forward to unit-test (UIs aren't). But for lots of things that unit-tests can't really cover so well, or for when we have to mock the entire universe anyway, we rely on UI tests. I'm not affiliated in any way, but I can honestly say that Ghost Inspector[0] made things WAY better for us. Why: * No more wrestling with capybara. Not having to constantly switch between the browser, test runner, IDE. Most tests don't take longer than 5 minutes to create from scratch. * We run UI tests on our staging environment, and we deploy all feature branches to staging before they get merged to master. UI tests are automatically run as soon as we deploy staging. And they run in parallel. So they're quite fast. * We plug the Ghost Inspector results into slack+email, so as soon as something breaks, we know immediately. Fixing the broken test is usually very straight-forward, and our developers do it (we don't have QA). Even if we need to re-record a test, it's usually much faster than re-writing a capybara/integration test. [0] https://ghostinspector.com/ https://ghostinspector.com/