- inside front cover
- Testing JavaScript Applications
- Copyright
- dedication
- contents
- front matter
- Part 1. Testing JavaScript applications
- 1 An introduction to automated testing
- 2 What to test and when?
- Part 2. Writing tests
- 3 Testing techniques
- 3.1 Organizing test suites
- 3.1.1 Breaking down tests
- 3.1.2 Parallelism
- 3.1.3 Global hooks
- 3.1.4 Atomicity
- 3.2 Writing good assertions
- 3.2.1 Assertions and error handling
- 3.2.2 Loose assertions
- 3.2.3 Using custom matchers
- 3.2.4 Circular assertions
- 3.3 Test doubles: Mocks, stubs, and spies
- 3.3.1 Mocking imports
- 3.4 Choosing what to test
- 3.4.1 Don’t test third-party software
- 3.4.2 To mock, or not to mock: That’s the question
- 3.4.3 When in doubt, choose integration tests
- 3.5 Code coverage
- 3.5.1 Automated coverage reports
- 3.5.2 Coverage types
- 3.5.3 What coverage is good for and what it isn’t
- Summary
- 4 Testing backend applications
- 5 Advanced backend testing techniques
- 6 Testing frontend applications
- 6.1 Introducing JSDOM
- 6.2 Asserting on the DOM
- 6.2.1 Making it easier to find elements
- 6.2.2 Writing better assertions
- 6.3 Handling events
- 6.4 Testing and browser APIs
- 6.4.1 Testing a localStorage integration
- 6.4.2 Testing a History API integration
- 6.5 Dealing with WebSockets and HTTP requests
- 6.5.1 Tests involving HTTP requests
- 6.5.2 Tests involving WebSockets
- Summary
- 7 The React testing ecosystem
- 8 Testing React applications
- 9 Test-driven development
- 9.1 The philosophy behind test-driven development
- 9.1.1 What test-driven development is
- 9.1.2 Adjusting the size of your iterations
- 9.1.3 Why adopt test-driven development?
- 9.1.4 When not to apply test-driven development
- 9.2 Writing a JavaScript module using TDD
- 9.3 Testing top-down versus testing bottom-up
- 9.3.1 What bottom-up and top-down testing mean
- 9.3.2 How top-down and bottom-up approaches impact a test-driven workflow
- 9.3.3 The pros and cons of bottom-up versus top-down approaches
- 9.4 Balancing maintenance costs, delivery speed, and brittleness
- 9.4.1 Test-driven implementation
- 9.4.2 Test-driven maintenance
- 9.5 Setting up an environment for TDD to succeed
- 9.5.1 Teamwide adoption
- 9.5.2 Keeping distinct lanes
- 9.5.3 Pairing
- 9.5.4 Supplementary testing
- 9.6 TDD, BDD, validations, and specificationsBDD (behavior-driven development)
- Summary
- 10 UI-based end-to-end testing
- 10.1 What are UI-based end-to-end tests?
- 10.2 When to write each type of test
- 10.2.1 UI-based end-to-end tests
- 10.2.2 Pure end-to-end tests
- 10.2.3 Pure UI tests
- 10.2.4 A note on acceptance testing and this chapter’s name
- 10.3 An overview of end-to-end testing tools
- 10.3.1 Selenium
- 10.3.2 Puppeteer
- 10.3.3 Cypress
- 10.3.4 When to choose Cypress
- Summary
- 11 Writing UI-based end-to-end tests
- 11.1 Your first UI-based end-to-end tests
- 11.1.1 Setting up a test environment
- 11.1.2 Writing your first tests
- 11.1.3 Sending HTTP requests
- 11.1.4 Sequencing actions
- 11.2 Best practices for end-to-end-tests
- 11.2.1 Page objects
- 11.2.2 Application actions
- 11.3 Dealing with flakiness
- 11.3.1 Avoiding waiting for fixed amounts of time
- 11.3.2 Stubbing uncontrollable factors
- 11.3.3 Retrying tests
- 11.4 Running tests on multiple browsers
- 11.4.1 Using a testing framework to run tests within a browser
- 11.4.2 Running UI-based tests in multiple browsers
- 11.5 Visual regression tests
- Summary
- Part 3. Business impact
- 12 Continuous integration and continuous delivery
- 13 A culture of quality
- 13.1 Using type systems to make invalid states unrepresentable
- 13.2 Reviewing code to catch problems machines can’t
- 13.3 Using linters and formatters to produce consistent code
- 13.4 Monitoring your systems to understand how they actually behave
- 13.5 Explaining your software with good documentation
- Summary
- index
- inside back cover
