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
Edit on GitHub
  1. Part 3: The Code
  2. Chapter 10: Testing our API

Testing the Response

Recall how we implemented the userResponseDto.

File: src/responses/userResponseDto.js

const userResponseDto = (user) => {
  return {
    id: user['id'],
    first_name: user['first_name'],
    last_name: user['last_name'],
    email: user['email'],
    phone_number: user['phone_number']
  }
}

module.exports = userResponseDto

You may look at this and feel a sense of déjà vu, and you would be right, because writing a test for the userResponseDto is quite similar to writing a test for the registerUserRequestDto.

As always we'll setup our test suite as follows.

File: src/responses/__tests/userResponseDto.test.js

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

describe('Test Suite: userResponseDto', () => {
  // Tests go here
})

The Tests

Since this is quite an easy function to test, let's add in some more test cases this time.

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

describe('Test Suite: Response', () => {
  test('Correct request 1 - empty parameters', () => {
    // 1. Arrange
    const user = {}

    // 2. Act
    const response = userResponseDto(user)

    // 3. Assert
    expect(response).toEqual({})
  })

  test('Correct request 2 - extra useless parameters', () => {
    // 1. Arrange
    const user = {
      id: '123',
      first_name: 'john',
      last_name: 'doe',
      email: 'johndoe@email.com',
      phone_number: '1234567890',
      password: 'undefined',
      extraParam1: null,
      extraParam2: 'whatzup',
      body: 'John Doe is cool'
    }

    // 2. Act
    const response = userResponseDto(user)

    // 3. Assert
    expect(response).toEqual({
      id: '123',
      first_name: 'john',
      last_name: 'doe',
      email: 'johndoe@email.com',
      phone_number: '1234567890'
    })
  })

  test('Correct request 3 - add password fields, hopefully they do not show up', () => {
    // 1. Arrange
    const user = {
      id: '123',
      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 response = userResponseDto(user)

    // 3. Assert
    expect(response).toEqual({
      id: '123',
      first_name: 'Yichen',
      last_name: 'Zhu',
      email: 'yichen@yichen.com',
      phone_number: '1234567890'
    })
  })
})
PreviousTesting the EventNextTesting the Controller

Last updated 3 years ago