The Feature Test

Let’s learn about the feature test.

We'll cover the following

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.