Listen up, folks! Here's my story on how I ran away from bug nests to enter Behavioral-Driven Development and realised that it will be hard for me to live without feature testing.
A long, long time ago, when my grey hair count was equal to zero (and my hopes were still high to grow a full beard), I discovered automated browser testing.
It was a sunny day in Wrocław. I was working on a relatively simple, documented-ish, and poorly tested project. The features were delivered, the unit and integration tests were passing, and the client was happy. Somehow, everything was going well—until we discovered that it wasn’t. We needed a way to test the entire application as a whole, from the signup process to whatever we were trying to provide for our users.
I have to admit, the person who saved the project back then was my client. Somebody who didn’t know about software development, but knew that what I was building was important for the business. The client clicked through the entire application a few times a day and in many different ways to find out if we can automate some processes even more—what was found out instead looked like a bug nest.
Nothing wakes me up like an email listing all the problems I had no idea about (sorry, coffee, I love you, but that’s the truth). These were simple bugs, but they were hard to find from unit test levels. What really drew my attention was that the email contained clear instructions on how the program should behave. I just needed to automate them to save time, code some more and profit.
Without knowing it, I was entering the world of Behaviour-Driven Development. It’s where everything starts from a described feature, but most importantly, where everyone speaks the same language. As a shopper you want to enter a discount code? What would that look like? Oh, you click here, input that and save some money. Awesome! Let me get on that. No technical talking, no ideas on implementation. The only task is to describe what needs to get done.
Now that we have more data about what we’re trying to accomplish, it’s a good time to start thinking about implementation. A correctly described feature will tell you how it wants to be implemented. “Given I’m a returning customer” could mean that our test user has used the app before and probably carries more data than a simple email and password, but it can also mean that we have to implement something else before we get into that part.
Feature tests help us stay focused on the most important tasks. While it’s tempting to prepare tests for the weirdest edge-cases, feature tests enforce the YAGNI principle. If you think you’re going to need something someday, that’s good. You’ll worry when that day arrives. Most of the time, the simplest possible solution is enough. Yes, you won’t have anything to brag about at the coffee machine, but we make tradeoffs every day.
Before I started testing features, I had a test suite with nice coverage and I enjoyed the look of green dots every single day. Every module worked as I expected them to and they did exactly what the client wanted. The problem was, it was not what the client needed. Communication about features and describing them as a list of steps that the user will perform, makes sure we get it right the first time. There are dozens of ways to implement any given feature, but our clients need only one of them. The best way to make sure they get what they want (and need) is to sit together and write out a strong feature spec.
At Netguru, testing is one of the essential steps in our project management process. What happens next? Read about code review and you'll see why we're into it, too!