Test-Driven Development with Java: Create higher-quality software by writing tests first with SOLID and hexagonal architecture

Cover
Title Page
Copyright and Credit
Dedicated
Contributors
Table of Contents
Preface
Part 1: How We Got to TDD
Chapter 1: Building the Case for TDD
Writing code badly
Understanding why bad code is written
Recognizing bad code
Bad variable names
Bad function, method, and class names
Error-prone constructs
Coupling and cohesion
Decreasing team performance
Diminishing business outcomes
Summary
Questions and answers
Further reading
Chapter 2: Using TDD to Create Good Code
Designing good quality code
Say what you mean, mean what you say
Take care of the details in private
Avoid accidental complexity
Revealing design flaws
Analyzing the benefits of writing tests before production code
Preventing logic flaws
Protecting against future defects
Documenting our code
Summary
Questions and answers
Further reading
Chapter 3: Dispelling Common Myths about TDD
Writing tests slows me down
Understanding the benefits of slowing down
Overcoming objections to tests slowing us down
Tests cannot prevent every bug
Understanding why people say tests cannot catch every bug
Overcoming objections to not catching every bug
How do you know the tests are right?
Understanding the concerns behind writing broken tests
Providing reassurance that we test our tests
TDD guarantees good code
Understanding problem-inflated expectations
Managing your expectations of TDD
Our code is too complex to test
Understanding the causes of untestable code
Reframing the relationship between good design and simple tests
Managing legacy code without tests
I don’t know what to test until I write the code
Understanding the difficulty of starting with testing
Overcoming the need to write production code first
Summary
Questions and answers
Further reading
Part 2: TDD Techniques
Chapter 4: Building an Application Using TDD
Technical requirements
Preparing our development environment
Installing the IntelliJ IDE
Setting up the Java project and libraries
Introducing the Wordz application
Describing the rules of Wordz
Exploring agile methods
Reading user stories – the building block of planning
Combining agile development with TDD
Summary
Questions and answers
Further reading
Chapter 5: Writing Our First Test
Technical requirements
Starting TDD: Arrange-Act-Assert
Defining the test structure
Working backward from outcomes
Increasing workflow efficiency
Defining a good test
Applying the FIRST principles
Using one assert per test
Deciding on the scope of a unit test
Catching common errors
Asserting exceptions
Only testing public methods
Preserving encapsulation
Learning from our tests
A messy Arrange step
A messy Act step
A messy Assert step
Limitations of unit tests
Code coverage – an often-meaningless metric
Writing the wrong tests
Beginning Wordz
Summary
Questions and answers
Chapter 6: Following the Rhythms of TDD
Technical requirements
Following the RGR cycle
Starting on red
Keep it simple – moving to green
Refactoring to clean code
Writing our next tests for Wordz
Summary
Questions and answers
Further reading
Chapter 7: Driving Design – TDD and SOLID
Technical requirements
Test guide – we drive the design
SRP – simple building blocks
Too many responsibilities make code harder to work with
Ability to reuse code
Simplified future maintenance
Counter-example – shapes code that violates SRP
Applying SRP to simplify future maintenance
Organizing tests to have a single responsibility
DIP – hiding irrelevant details
Applying DI to the shapes code
LSP – swappable objects
Reviewing LSP usage in the shapes code
OCP – extensible design
Adding a new type of shape
ISP – effective interfaces
Reviewing ISP usage in the shapes code
Summary
Questions and answers
Chapter 8: Test Doubles – Stubs and Mocks
Technical requirements
The problems collaborators present for testing
The challenges of testing unrepeatable behavior
The challenges of testing error handling
Understanding why these collaborations are challenging
The purpose of test doubles
Making the production version of the code
Using stubs for pre-canned results
When to use stub objects
Using mocks to verify interactions
Understanding when test doubles are appropriate
Avoiding the overuse of mock objects
Don’t mock code you don’t own
Don’t mock value objects
You can’t mock without dependency injection
Don’t test the mock
When to use mock objects
Working with Mockito – a popular mocking library
Getting started with Mockito
Writing a stub with Mockito
Writing a mock with Mockito
Blurring the distinction between stubs and mocks
Argument matchers – customizing behavior of test doubles
Driving error handling code with tests
Testing an error condition in Wordz
Summary
Questions and answers
Further reading
Chapter 9: Hexagonal Architecture –Decoupling External Systems
Technical requirements
Why external systems are difficult
Environmental problems bring trouble
Accidentally triggering real transactions from tests
What data should we expect?
Operating system calls and system time
Challenges with third-party services
Dependency inversion to the rescue
Generalizing this approach to the hexagonal architecture
Overview of the hexagonal architecture’s components
The golden rule – the domain never connects directly to adapters
Why the hexagon shape?
Abstracting out the external system
Deciding what our domain model needs
Writing the domain code
Deciding what should be in our domain model
Using libraries and frameworks in the domain model
Deciding on a programming approach
Substituting test doubles for external systems
Replacing the adapters with test doubles
Unit testing bigger units
Unit testing entire user stories
Wordz – abstracting the database
Designing the repository interface
Designing the database and random numbers adapters
Summary
Questions and answers
Further reading
Chapter 10: FIRST Tests and the Test Pyramid
Technical requirements
The test pyramid
Unit tests – FIRST tests
Integration tests
What should an integration test cover?
Testing database adapters
Testing web services
Consumer-driven contract testing
End-to-end and user acceptance tests
Acceptance testing tools
CI/CD pipelines and test environments
What is a CI/CD pipeline?
Why do we need continuous integration?
Why do we need continuous delivery?
Continuous delivery or continuous deployment?
Practical CI/CD pipelines
Test environments
Testing in production
Wordz – integration test for our database
Fetching a word from the database
Summary
Questions and answers
Further reading
Chapter 11: Exploring TDD with Quality Assurance
TDD – its place in the bigger quality picture
Understanding the limits of TDD
No more need for manual testing?
Manual exploratory – discovering the unexpected
Code review and ensemble programming
User interface and user experience testing
Testing the user interface
Evaluating the user experience
Security testing and operations monitoring
Incorporating manual elements into CI/CD workflows
Summary
Questions and answers
Further reading
Chapter 12: Test First, Test Later, Test Never
Adding tests first
Test-first is a design tool
Tests form executable specifications
Test-first provides meaningful code coverage metrics
Beware of making a code coverage metric a target
Beware of writing all tests upfront
Writing tests first helps with continuous delivery
We can always test it later, right?
Test-later is easier for a beginner to TDD
Test-later makes it harder to test every code path
Test-later makes it harder to influence the software design
Test-later may never happen
Tests? They’re for people who can’t write code!
What happens if we do not test during development?
Testing from the inside out
Testing from the outside in
Defining test boundaries with hexagonal architecture
Inside-out works well with the domain model
Outside-in works well with adapters
User stories can be tested across the domain model
Summary
Questions and answers
Further reading
Part 3: Real-World TDD
Chapter 13: Driving the Domain Layer
Technical requirements
Starting a new game
Test-driving starting a new game
Tracking the progress of the game
Triangulating word selection
Playing the game
Designing the scoring interface
Triangulating game progress tracking
Ending the game
Responding to a correct guess
Triangulating the game over due to too many incorrect guesses
Triangulating response to guess after game over
Reviewing our design
Summary
Questions and answers
Further reading
Chapter 14: Driving the Database Layer
Technical requirements
Installing the Postgres database
Creating a database integration test
Creating a database test with DBRider
Driving out the production code
Implementing the WordRepository adapter
Accessing the database
Implementing GameRepository
Summary
Questions and answers
Further reading
Chapter 15: Driving the Web Layer
Technical requirements
Starting a new game
Adding required libraries to the project
Writing the failing test
Creating our HTTP server
Adding routes to the HTTP server
Connecting to the domain layer
Refactoring the start game code
Handling errors when starting a game
Fixing the unexpectedly failing tests
Playing the game
Integrating the application
Using the application
Summary
Questions and answers
Further reading
Index
Other Books You May Enjoy