First, we begin our development by writing tests. Since the validation logic of the Login endpoint works in the same way as our endpoints, we can simply copy those scenarios from our other tests:
Feature: Login User
Test that we can create a user using a digest and then perform a login that returns successfully
Background: Create User with email and password digest
Given 1 new user is created with random password and email
Scenario Outline: Bad Client Requests
...
Scenario Outline: Bad Request Payload
...
Scenario Outline: Request Payload with Properties of Unsupported Type
...
Scenario Outline: Request Payload with invalid email format
...
Scenario Outline: Request Payload with invalid digest format
...
Next, we can specify scenarios specific to the Login endpoint:
Scenario: Login without supplying credentials
When the client creates a POST request to /login
And sends the request
Then our API should respond with a 400 HTTP status code
Scenario: Login attaching a well-formed payload
When the client creates a POST request to /login
And attaches a valid Login payload
And sends the request
Then our API should respond with a 200 HTTP status code
And the payload of the response should be a string
Scenario Outline: Login attaching a well-formed payload but invalid credentials
When the client creates a POST request to /login
And attaches a Login payload where the <field> field is exactly <value>
And sends the request
Then our API should respond with a 403 HTTP status code
Examples:
| field | value |
| email | non@existent.email |
| digest | $2a$10$enCaroMp4gMvEmvCe4EuP.0d5FZ6yc0yUuSJ0pQTt4EO5MXvonUTm |
In the second scenario (Login attaching a well-formed payload), the response body should be an identification object. However, before we decide on how to implement this object, we can simply test that a string is returned.