book

The Art of Unit Testing, Third Edition

Name: The Art of Unit Testing, Third Edition
ISBN: 9781617297489

by Roy Osherove, Vladimir Khorikov

March 2024

Intermediate to advanced

288 pages

7h 49m

English

Manning Publications

Read now

Unlock full access

inside front cover
Praise for the second edition
The Art of Unit Testing
Copyright
dedication
contents
Front matter
foreword to the second editionforeword to the first editionprefaceacknowledgmentsabout this bookWhat’s new in the third editionWho should read this bookHow this book is organized: A road mapCode conventions and downloadsSoftware requirementsliveBook discussion forumOther projects by Roy OsheroveOther projects by Vladimir Khorikovabout the authorsabout the cover illustration
Part 1 Getting started
1 The basics of unit testing
1.1 The first step1.2 Defining unit testing, step by step1.3 Entry points and exit points1.4 Exit point types1.5 Different exit points, different techniques1.6 A test from scratch1.7 Characteristics of a good unit test1.7.1 What is a good unit test?1.7.2 A unit test checklist1.8 Integration tests1.9 Finalizing our definition1.10 Test-driven development1.10.1 TDD: Not a substitute for good unit tests1.10.2 Three core skills needed for successful TDDSummary
2 A first unit test
2.1 Introducing Jest2.1.1 Preparing our environment2.1.2 Preparing our working folder2.1.3 Installing Jest2.1.4 Creating a test file2.1.5 Executing Jest2.2 The library, the assert, the runner, and the reporter2.3 What unit testing frameworks offer2.3.1 The xUnit frameworks2.3.2 xUnit, TAP, and Jest structures2.4 Introducing the Password Verifier project2.5 The first Jest test for verifyPassword2.5.1 The Arrange-Act-Assert pattern2.5.2 Testing the test2.5.3 USE naming2.5.4 String comparisons and maintainability2.5.5 Using describe()2.5.6 Structure implying context2.5.7 The it() function2.5.8 Two Jest flavors2.5.9 Refactoring the production code2.6 Trying the beforeEach() route2.6.1 beforeEach() and scroll fatigue2.7 Trying the factory method route2.7.1 Replacing beforeEach() completely with factory methods2.8 Going full circle to test()2.9 Refactoring to parameterized tests2.10 Checking for expected thrown errors2.11 Setting test categoriesSummary

Part 2 Core techniques
3 Breaking dependencies with stubs
3.1 Types of dependencies3.2 Reasons to use stubs3.3 Generally accepted design approaches to stubbing3.3.1 Stubbing out time with parameter injection3.3.2 Dependencies, injections, and control3.4 Functional injection techniques3.4.1 Injecting a function3.4.2 Dependency injection via partial application3.5 Modular injection techniques3.6 Moving toward objects with constructor functions3.7 Object-oriented injection techniques3.7.1 Constructor injection3.7.2 Injecting an object instead of a function3.7.3 Extracting a common interfaceSummary
4 Interaction testing using mock objects
4.1 Interaction testing, mocks, and stubs4.2 Depending on a logger4.3 Standard style: Introduce parameter refactoring4.4 The importance of differentiating between mocks and stubs4.5 Modular-style mocks4.5.1 Example of production code4.5.2 Refactoring the production code in a modular injection style4.5.3 A test example with modular-style injection4.6 Mocks in a functional style4.6.1 Working with a currying style4.6.2 Working with higher-order functions and not currying4.7 Mocks in an object-oriented style4.7.1 Refactoring production code for injection4.7.2 Refactoring production code with interface injection4.8 Dealing with complicated interfaces4.8.1 Example of a complicated interface4.8.2 Writing tests with complicated interfaces4.8.3 Downsides of using complicated interfaces directly4.8.4 The interface segregation principle4.9 Partial mocks4.9.1 A functional example of a partial mock4.9.2 An object-oriented partial mock exampleSummary
5 Isolation frameworks
5.1 Defining isolation frameworks5.1.1 Choosing a flavor: Loose vs. typed5.2 Faking modules dynamically5.2.1 Some things to notice about Jest’s API5.2.2 Consider abstracting away direct dependencies5.3 Functional dynamic mocks and stubs5.4 Object-oriented dynamic mocks and stubs5.4.1 Using a loosely typed framework5.4.2 Switching to a type-friendly framework5.5 Stubbing behavior dynamically5.5.1 An object-oriented example with a mock and a stub5.5.2 Stubs and mocks with substitute.js5.6 Advantages and traps of isolation frameworks5.6.1 You don’t need mock objects most of the time5.6.2 Unreadable test code5.6.3 Verifying the wrong things5.6.4 Having more than one mock per test5.6.5 Overspecifying the testsSummary
6 Unit testing asynchronous code
6.1 Dealing with async data fetching6.1.1 An initial attempt with an integration test6.1.2 Waiting for the act6.1.3 Integration testing of async/await6.1.4 Challenges with integration tests6.2 Making our code unit-test friendly6.2.1 Extracting an entry point6.2.2 The Extract Adapter pattern6.3 Dealing with timers6.3.1 Stubbing timers out with monkey-patching6.3.2 Faking setTimeout with Jest6.4 Dealing with common events6.4.1 Dealing with event emitters6.4.2 Dealing with click events6.5 Bringing in the DOM testing librarySummary
Part 3 The test code
7 Trustworthy tests
7.1 How to know you trust a test7.2 Why tests fail7.2.1 A real bug has been uncovered in the production code7.2.2 A buggy test gives a false failure7.2.3 The test is out of date due to a change in functionality7.2.4 The test conflicts with another test7.2.5 The test is flaky7.3 Avoiding logic in unit tests7.3.1 Logic in asserts: Creating dynamic expected values7.3.2 Other forms of logic7.3.3 Even more logic7.4 Smelling a false sense of trust in passing tests7.4.1 Tests that don’t assert anything7.4.2 Not understanding the tests7.4.3 Mixing unit tests and flaky integration tests7.4.4 Testing multiple exit points7.4.5 Tests that keep changing7.5 Dealing with flaky tests7.5.1 What can you do once you’ve found a flaky test?7.5.2 Preventing flakiness in higher-level testsSummary
8 Maintainability
8.1 Changes forced by failing tests8.1.1 The test is not relevant or conflicts with another test8.1.2 Changes in the production code’s API8.1.3 Changes in other tests8.2 Refactoring to increase maintainability8.2.1 Avoid testing private or protected methods8.2.2 Keep tests DRY8.2.3 Avoid setup methods8.2.4 Use parameterized tests to remove duplication8.3 Avoid overspecification8.3.1 Internal behavior overspecification with mocks8.3.2 Exact outputs and ordering overspecificationSummary
Part 4 Design and process
9 Readability
9.1 Naming unit tests9.2 Magic values and naming variables9.3 Separating asserts from actions9.4 Setting up and tearing downSummary
10 Developing a testing strategy
10.1 Common test types and levels10.1.1 Criteria for judging a test10.1.2 Unit tests and component tests10.1.3 Integration tests10.1.4 API tests10.1.5 E2E/UI isolated tests10.1.6 E2E/UI system tests10.2 Test-level antipatterns10.2.1 The end-to-end-only antipattern10.2.2 The low-level-only test antipattern10.2.3 Disconnected low-level and high-level tests10.3 Test recipes as a strategy10.3.1 How to write a test recipe10.3.2 When do I write and use a test recipe?10.3.3 Rules for a test recipe10.4 Managing delivery pipelines10.4.1 Delivery vs. discovery pipelines10.4.2 Test layer parallelizationSummary
11 Integrating unit testing into the organization
11.1 Steps to becoming an agent of change11.1.1 Be prepared for the tough questions11.1.2 Convince insiders: Champions and blockers11.1.3 Identify possible starting points11.2 Ways to succeed11.2.1 Guerrilla implementation (bottom-up)11.2.2 Convincing management (top-down)11.2.3 Experiments as door openers11.2.4 Get an outside champion11.2.5 Make progress visible11.2.6 Aim for specific goals, metrics, and KPIs11.2.7 Realize that there will be hurdles11.3 Ways to fail11.3.1 Lack of a driving force11.3.2 Lack of political support11.3.3 Ad hoc implementations and first impressions11.3.4 Lack of team support11.4 Influence factors11.5 Tough questions and answers11.5.1 How much time will unit testing add to the current process?11.5.2 Will my QA job be at risk because of unit testing?11.5.3 Is there proof that unit testing helps?11.5.4 Why is the QA department still finding bugs?11.5.5 We have lots of code without tests: Where do we start?11.5.6 What if we develop a combination of software and hardware?11.5.7 How can we know we don’t have bugs in our tests?11.5.8 Why do I need tests if my debugger shows that my code works?11.5.9 What about TDD?Summary
12 Working with legacy code
12.1 Where do you start adding tests?12.2 Choosing a selection strategy12.2.1 Pros and cons of the easy-first strategy12.2.2 Pros and cons of the hard-first strategy12.3 Writing integration tests before refactoring12.3.1 Read Michael Feathers’ book on legacy code12.3.2 Use CodeScene to investigate your production codeSummary
appendix. Monkey-patching functions and modules
A.1 An obligatory warningA.2 Monkey-patching functions, globals, and possible issuesA.2.1 Monkey-patching a function the Jest wayA.2.2 Jest spiesA.2.3 spyOn with mockImplementation()A.3 Ignoring a whole module with Jest is simpleA.4 Faking module behavior in each testA.4.1 Stubbing a module with vanilla require.cacheA.4.2 Stubbing custom module data with Jest is complicatedA.4.3 Avoid Jest’s manual mocksA.4.4 Stubbing a module with Sinon.jsA.4.5 Stubbing a module with testdouble
index

Content preview from The Art of Unit Testing, Third Edition

4 Interaction testing using mock objects

This chapter covers

Defining interaction testing
Reasons to use mock objects
Injecting and using mocks
Dealing with complicated interfaces
Partial mocks

In the previous chapter, we solved the problem of testing code that depends on other objects to run correctly. We used stubs to make sure that the code under test received all the inputs it needed so that we could test the unit of work in isolation.

So far, you’ve only written tests that work against the first two of the three types of exit points a unit of work can have: returning a value and changing the state of the system (you can read more about these types in chapter 1). In this chapter, we’ll look at how you can test the third type of exit point—a ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9781617297489Publisher Support Publisher Website

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

The Art of Unit Testing, Third Edition

by Roy Osherove, Vladimir Khorikov

4 Interaction testing using mock objects

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.