The Feature Test

Let’s learn about the feature test.

Testing what users can see

The feature test and a user story are the same thing. They both describe how the user achieves a goal by interacting with the interface we’ve provided

Coding starts after we have our feature test written.

To simplify things, we’ll use an example that fits most SaaS products, the sign-up (or registration) story. Let’s apply the testing wheel process to it.

The feature test

Below is a simple feature test:

Press + to interact
Feature: User registration
As a first-time visitor
I want to be able to create an account
So that I can access the member's area
Scenario: I create an account
Given I am on the homepage
When I click on the registration link
And I fill in and submit the registration form
Then I should see a registration confirmation message
And I should receive a confirmation email

Notice how the feature description provides the context. It tells us why our users need this feature built and how it creates value.

The scenario, also known as acceptance criteria, is the user story copied inside a test file. It’s executable code because each line in the file corresponds to some code that we put in other files. Each of the different lines in the scenario is called a step.

For now, there’s just one scenario, but a complete feature usually has a few more. We build these by asking what-if questions.

Now that we have something to work with, we can sit down at our keyboard and start making things happen. But the way we do that is important—we should let the test guide us.

Writing implementation code becomes easier when we start with a test because we don’t have to keep as many details in our heads. We simply run the test and it tells us what to do next.

We can walk away from our desks and be back hours later, knowing exactly where we left off.