My aha! moment with test-driven development were acceptance tests and I recommend everyone who is still a skeptic to start there.
Many years ago I was working on a Ruby on Rails app with a multi-step booking process. Each step had many possible states and outcomes.
Testing that manually after every change in code was painfully repetitive, slow, and embarrassingly unreliable. 😓
Getting anything done was hard. We’d change one thing, then spend about an hour on manual testing in the web browser to check if everything is still working.
We’d often be surprised by the fact that we broke a seemingly unrelated use case. 🤯
Sometimes we’d figure that out on our own, and sometimes we’d ship a new version to production and the client would email us about what had just stopped working.
Getting that kind of news felt the worst. It felt like we were wasting a lot of our client’s and our own time. 👎
Then, we discovered Cucumber.
Very easy to get started. We could write a test once, and it would automatically launch a web browser, run the application, and do the work of feature verification instead of us.
That felt like magic! 🪄 ✨
As soon as we started writing acceptance tests for a feature we had been working on, our development accelerated by an order of magnitude. 🚀
We could add and change code without worrying that we would break something. 😌
When something did break, a failing scenario would let us know, and we’d quickly fix it before deploying a new version to users. 🦄
So to all teams out there who don't write (much) tests, I Hundred points symbol recommend starting with acceptance tests.
The ROI — in peace of mind, reliability, velocity, and good feeling — of writing just a few is massive.
From that point on, it's really a downhill ride to adopting a test-driven mindset for all layers of code. 💪
Originally published as a Twitter thread.