RESTful Node.js: A Structured Approach
  • Book Cover
  • About the Author
  • Links and Resources
  • Part I: The Why
    • Foreword
    • Preface
    • Chapter 1: Introduction
      • The Rise of REST and Distributed Systems
      • Problem #1: Structureless Design, Structureless REST
      • The Emergence of JavaScript and Node.js
      • Problem #2: Structureless JavaScript, Structureless Node.js
      • Behold, the Solution: A Structured Approach
      • Summary
  • Part 2: The Theory
    • Chapter 2: REST Origins
      • A Brief History of the Web and the Birth of REST
      • REST vs. HTTP
      • REST - The Abstract Web Architecture
      • HTTP - A Peak at REST's Concrete Implementation
      • What does it mean for an API to be RESTful?
      • Measuring "RESTfulness" with Richardson Maturity Model
      • Pragmatic REST vs Dogmatic REST
      • Summary
    • Chapter 3: RESTful API Design Guidelines and "Best Practices"
      • Theories vs. Principles vs. Guidelines
      • URI Design
      • Method Verbs
      • Status Codes
      • Representational Design
      • Metadata Design
      • Versioning Strategies
      • Security Considerations
      • Documentation
      • Case Study: GitHub
      • Summary
    • Chapter 4: Structured JavaScript Architecture
      • The Monstrous Monolith and Its Downfall
      • Layered/N-Tier Architecture: The Unpopular Proven Way
      • Microservices and Distributed Computing: A Popular Misdirection
      • Summary
    • Chapter 5: The 8 Step Recipe
      • Route Name (URI)
      • Input Request
      • Middleware
      • Validation
      • Domain
      • Events
      • Output Response
      • Test, Refactor, Document
      • Summary
  • Part 3: The Code
    • Chapter 6: Introduction to the Bookstore API
      • The Bookstore API Endpoint Specifications
      • API Design and Code Structure
      • Project Setup
      • Summary
    • Chapter 7: Retrieving Books from our API
      • Retrieving All Books - Planning
      • Retrieving All Books - Implementation
      • Retrieving A Book By ID - Planning
      • Retrieving A Book By ID - Implementation
      • Summary
    • Chapter 8: Adding Authentication to our API
      • Registering the User - Planning
      • Registering the User - Implementation
      • Logging the User In - Planning
      • Logging the User In - Implementation
      • Getting Authenticated User - Planning
      • Getting Authenticated User - Implementation
      • Summary
    • Chapter 9: Adding the Create, Update, and Delete Operations to our API
      • Creating A Book Listing - Planning
      • Creating A Book Listing - Implementation
      • Updating A Book Listing By ID - Planning
      • Updating A Book Listing By ID - Implementation
      • Deleting A Book Listing By ID - Planning
      • Deleting A Book Listing By ID - Implementation
      • Summary
    • Chapter 10: Testing our API
      • Testing the Request
      • Testing the Middleware
      • Testing the Validation
      • Testing the Domain
      • Testing the Event
      • Testing the Response
      • Testing the Controller
      • Integration Test
      • Summary
  • Conclusion
    • Final Words
  • Bonus!
    • Refactoring to HATEOAS
  • Appendix
    • Sources & References
Powered by GitBook
On this page
  • The Passing Test
  • The Failing Test
Edit on GitHub
  1. Part 3: The Code
  2. Chapter 10: Testing our API

Testing the Request

Recall how we implemented the registerUserRequestDto.

File: src/requests/registerUserRequestDto.js

const path = require('path')
const ApiException = require('../utils/ApiException')

const fields = [
  'first_name',
  'last_name',
  'email',
  'password',
  'password_confirmation',
  'phone_number'
]

/**
 * @param Object data
 */
const registerUserRequestDto = (data) => {
  const errors = []
  fields.forEach((field) => {
    if (!(field in data)) {
      errors.push(`This DTO's property is required: ${field}.`)
    }
  })

  if (errors.length > 0) {
    throw new ApiException({
      status: 'error',
      code: 422,
      message: 'Input fields are of not the correct form.',
      data: null,
      errors
    })
  }

  return data
}

module.exports = registerUserRequestDto

We'll first setup our test suite.

We'll be working mainly in this file for the rest of this section.

File: src/requests/__tests__/registerUserRequestDto.test.js

const registerUserRequestDto = require('../registerUserRequestDto')

describe('Test Suite: registerUserRequestDto', () => {
  // tests go here...
})

I personally always like to write at least 1 test for both a passing and failing scenario.

Of course you can always write more tests to cover more additional scenarios and edge cases . For our purposes, we'll just be sticking to writing 1 passing test and 1 failing test.

The Passing Test

The first one is simple, let's add in all the required fields in registerUserRequestDto and expect what we want out of it.

test('Request 1 - all required fields', () => {
  // 1. Arrange
  const inputRequest = {
    first_name: 'Yichen',
    last_name: 'Zhu',
    email: 'yichen@yichen.com',
    password: 'yichen-and-his-awesome-password',
    password_confirmation: 'yichen-and-his-awesome-password',
    phone_number: '1234567890'
  }

  // 2. Act
  const registerUserRequest = registerUserRequestDto(inputRequest)

  // 3. Assert
  expect(registerUserRequest).toEqual({
    first_name: 'Yichen',
    last_name: 'Zhu',
    email: 'yichen@yichen.com',
    password: 'yichen-and-his-awesome-password',
    password_confirmation: 'yichen-and-his-awesome-password',
    phone_number: '1234567890'
  })
})

The Failing Test

The next test case is what happens if we don't pass the correct inputs into the registerUserRequestDto function. We would expect an error, and not just any error, but an ApiException error being thrown.

test('Request 2 - missing input fields', () => {
  // 1. Arrange
  const inputRequest = { message: 'this is awesome!' }

  // 2. Act + 3. Assert
  expect(() => {
    registerUserRequestDto(inputRequest)
  }).toThrow(ApiException)
})
PreviousChapter 10: Testing our APINextTesting the Middleware

Last updated 3 years ago