The Art of Unit Testing, Third Edition MEAP V07
Copyright
Welcome
Brief contents
Part 1: Getting started
1: The basics of unit testing
1.1 The first step
1.2 Defining unit testing, step by step
1.3 Entry Points & Exit Points
1.4 Exit Point Types
1.5 Different Exit Points, Different Techniques
1.6 A Test from Scratch
1.7 Characteristics of a good unit test
1.7.1 So, what’s a “good” unit test?
1.7.2 A simple checklist
1.8 Integration tests
1.8.1 Drawbacks of integration tests compared to automated unit tests
1.9 Finalizing our definition
1.10 What About Regression Tests?
1.11 Test-driven development
1.12 Three core skills needed for successful TDD
1.13 Summary
2: A first unit test
2.1 About Jest
2.1.1 Preparing our environment
2.1.2 Preparing our working folder
2.1.3 Installing Jest
2.1.4 Creating a test file
2.1.5 Executing Jest:
2.2 The Library, the Assert, the Runner & the Reporter
2.3 What unit testing frameworks offer
2.3.1 The xUnit frameworks
2.3.2 XUnit, TAP and Jest Structures
2.4 Introducing the Password Verifier Project
2.5 The first Jest test for verifyPassword
2.5.1 Testing the test
2.5.2 U.S.E Naming
2.5.3 String comparisons and maintainability
2.5.4 Using describe()
2.5.5 Structure can imply context
2.5.6 The ‘It’ function
2.5.7 Two Jest Flavors
2.5.8 Refactoring the Production Code
2.6 Trying the beforeEach() route
2.6.1 beforeEach() and scroll fatigue
2.7 Trying the factory method route
2.7.1 Replacing beforeEach() completely with factory methods.
2.8 Going Full Circle to test()
2.9 Refactoring to parameterized tests
2.10 Checking for expected thrown errors
2.11 Setting Test Categories
2.12 Summary
3: Breaking dependencies with stubs
3.1 Types of Dependencies
3.2 Reasons to use stubs
3.3 Generally accepted design approaches to stubbing
3.3.1 Stubbing out time with parameter injection
3.3.2 Dependencies, Injections and Control
3.4 Functional Injection Techniques
3.4.1 Injecting a function
3.4.2 Using Factory Functions
3.4.3 Moving Towards Objects with Constructor Functions
3.5 Object Oriented Injection Techniques
3.5.1 Constructor Injection
3.5.2 Injecting an object instead of a function
3.5.3 Extracting a common interface.
3.6 Summary
4: Interaction testing using mock objects
4.1 Interaction Testing, Mocks and Stubs
4.2 Depending on a logger
4.3 Standard Style: Introduce Parameter Refactoring
4.4 The Importance of Mock and Stub Differentiation
4.5 Modular Style Mocks
4.5.1 Example of production code
4.5.2 Refactoring the production code in a modular injection style
4.5.3 A test example with modular style injection
4.6 Mocks in a Functional Style
4.6.1 Working with a currying Style
4.6.2 Working with higher order functions and not currying
4.7 Mocks in an Object-Oriented Style
4.7.1 Refactoring Production Code for Injection
4.7.2 Refactoring Production with Interface Injection
4.8 Dealing with complicated interfaces
4.8.1 Example of a Complicated Interface
4.8.2 Writing tests with complicated interfaces
4.8.3 Downsides of using Complicated Interfaces directly
4.8.4 The Interface Segregation Principle
4.9 Partial Mocks
4.9.1 A Functional Partial Mock Example
4.9.2 An Object Oriented Partial Mock Example
4.10 What about Spies?
4.11 Summary
5: Isolation (mocking) frameworks
5.1 Defining Isolation Frameworks
5.2 A quick look at the Isolation frameworks landscape
5.3 Choosing a loose vs typed “flavor”
5.4 Faking Modules Dynamically
5.4.1 Some things to notice about jest’s API:
5.4.2 Consider abstracting away direct dependencies
5.5 Functional Mocks and Stubs - Dynamically
5.6 Object Oriented Dynamic Mocks and Stubs
5.6.1 Switching to a type-friendly Isolation Framework
5.7 Stubbing Behavior Dynamically
5.7.1 An Object-Oriented example with a mock and a stub
5.7.2 Stubs and Mocks with Substitute.JS
5.8 Advantages and traps of isolation frameworks
5.8.1 You don’t need mock objects most of the time
5.8.2 Unreadable test code
5.8.3 Verifying the wrong things
5.8.4 Having more than one mock per test
5.8.5 Over specifying the tests
5.9 Summary
6: Unit Testing Async Code
6.1 Dealing with Async Data Fetching
6.1.1 An initial attempt with an integration test
6.1.2 Waiting for the act
6.1.3 Integration testing async-await
6.1.4 Challenges with integration tests
6.2 Making our code unit test friendly
6.2.1 Extracting a Logical Unit of Work
6.2.2 Applying “Extract Entry Point” with Callbacks
6.2.3 Extract Entry Point with Await
6.3 Extract Adapter Pattern
6.3.1 Modular Adapter
6.3.2 Functional Adapter
6.3.3 Object Oriented Interface Based Adapter
6.4 Dealing with Timers
6.4.1 Stubbing timers out with Monkey Patching
6.4.2 Faking setTimeout with jest
6.5 Dealing with Common Events
6.5.1 Dealing with event emitters
Event Emitters
6.5.2 Dealing with Click events
6.6 Bringing in dom-testing-library
6.7 Summary
7: Trustworthy Tests
7.1 How to know you trust a test
7.2 Why Tests Fail (and how it can help us)
7.3 A real bug has been uncovered in the production code. (good!)
7.4 Buggy (lying) test
7.4.1 How to recognize a buggy (lying) test
7.4.2 What do we do once we’ve established a buggy test?
7.4.3 Reducing or avoiding buggy tests in the future
7.4.4 Avoiding logic in unit tests
7.4.5 Logic in asserts – creating dynamic expected values
7.4.6 Other forms of logic
7.4.7 Even more logic
7.5 Out of Date test (feature changed)
7.5.1 What can we do now?
7.5.2 Avoiding or preventing this in the future
7.6 Conflicting test (with another test)
7.6.1 What can we do now?
7.6.2 Avoiding this in the future
7.7 Flaky Test
7.8 Smelling a false sense of trust in passing tests
7.8.1 Tests that don’t assert anything
7.8.2 Not understanding the tests
7.8.3 Mixing Unit & Integration (Flaky) Tests
7.8.4 Having logic inside unit tests
7.8.5 Testing multiple concerns (entry/exit points)
7.8.6 Tests that keep changing
7.9 Dealing with Flaky Tests
7.9.1 Detecting Flakiness:
7.9.2 Flaky tests take more time to run and understand.
7.9.3 What can you do once you’ve found a flaky test?
7.9.4 Preventing flakiness in higher level tests
7.10 Summary
8: Maintainability
8.1 Root causes for test changes
8.2 Forced changes by failing tests
8.2.1 Breaking when there’s a production bug (great!)
8.2.2 Breaking when a test has a bug (increase trust)
8.2.3 Breaking when a test is not relevant, or conflicts with another test (remove)
8.2.4 Breaking when the Semantics or API in our production code change
8.2.5 Breaking when some other tests or test code changes (decrease test coupling)
8.3 Refactoring to increase maintainability
8.3.1 Avoid Testing private or protected methods
8.3.2 Remove duplication
8.3.3 Avoid setup methods( in a maintainable manner)
8.3.4 Using parameterized tests to remove duplication
8.4 Avoid overspecification
8.4.1 Internal behavior overspecification with mocks
8.4.2 Exact outputs and ordering overspecification
8.5 Summary
9: Readability
9.1 Naming unit tests
9.2 Magic Values and Naming variables
9.3 Separating asserts from actions
9.4 Setting up and tearing down
9.5 Summary