Asserting results

Now, let's move on to our next step definition, which is an assertion step. In there, we should assert that the response from our server should have a 400 HTTP status code:

Then('our API should respond with a 400 HTTP status code', function () {
  if (error.statusCode !== 400) {
    throw new Error();
  }
});

Now, with our API server running in the background, run our E2E tests again. You should see the result of the second step changing from pending to failed:

$ yarn run test:e2e
...F--

Failures:
1) Scenario: Empty Payload
    When the client creates a POST request to /users
    And attaches a generic empty payload
   And sends the request
   Then our API should respond with a 400 HTTP status code
       {}
       Error
           at World.<anonymous> (spec/cucumber/steps/index.js:28:11)
   - And the payload of the response should be a JSON object
   - And contains a message property which says "Payload should not be empty"

1 scenario (1 failed)
6 steps (1 failed, 2 skipped, 3 passed)

It fails because our API is currently always returning the Hello World string with the HTTP status code of 200, regardless of what the request is. But this is nothing to be concerned about! Writing a failing test is the first step of the TDD workflow; now, we just need to write the minimum amount to code to make the test pass.

To make our fourth step pass, we must check the method and path of the req object in the requestHandler function, and if it matches POST and /users, respectively, we will send back a 400 response. 

But how do we know the structure of the req object? We can use console.log to print it onto the console, but the structure of objects such as req and res are complex and the output is going to be hard to read. Instead, we should use a debugger.