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