book

Test-Driven Development with Java

Name: Test-Driven Development with Java
Author: Alan Mellor
ISBN: 9781803236230

by Alan Mellor

January 2023

Intermediate to advanced

348 pages

8h 29m

English

Packt Publishing

Read now

Unlock full access

Test-Driven Development with Java
ContributorsAbout the authorAbout the reviewers
Preface
Who this book is forWhat this book coversTo get the most out of this bookDownload the example code filesDownload the color imagesConventions usedGet in touchShare Your ThoughtsDownload a free PDF copy of this book
Part 1: How We Got to TDD
Chapter 1: Building the Case for TDD
Writing code badlyUnderstanding why bad code is writtenRecognizing bad codeBad variable namesBad function, method, and class namesError-prone constructsCoupling and cohesionDecreasing team performanceDiminishing business outcomesSummaryQuestions and answersFurther reading
Chapter 2: Using TDD to Create Good Code
Designing good quality codeSay what you mean, mean what you sayTake care of the details in privateAvoid accidental complexityRevealing design flawsAnalyzing the benefits of writing tests before production codePreventing logic flawsProtecting against future defectsDocumenting our codeSummary Questions and answers Further reading
Chapter 3: Dispelling Common Myths about TDD
Writing tests slows me downUnderstanding the benefits of slowing downOvercoming objections to tests slowing us downTests cannot prevent every bugUnderstanding why people say tests cannot catch every bugOvercoming objections to not catching every bugHow do you know the tests are right?Understanding the concerns behind writing broken testsProviding reassurance that we test our testsTDD guarantees good codeUnderstanding problem-inflated expectationsManaging your expectations of TDDOur code is too complex to testUnderstanding the causes of untestable codeReframing the relationship between good design and simple testsManaging legacy code without testsI don’t know what to test until I write the codeUnderstanding the difficulty of starting with testingOvercoming the need to write production code firstSummaryQuestions and answersFurther reading
Part 2: TDD Techniques
Chapter 4: Building an Application Using TDD
Technical requirementsPreparing our development environmentInstalling the IntelliJ IDESetting up the Java project and librariesIntroducing the Wordz applicationDescribing the rules of WordzExploring agile methodsReading user stories – the building block of planningCombining agile development with TDDSummaryQuestions and answersFurther reading
Chapter 5: Writing Our First Test
Technical requirementsStarting TDD: Arrange-Act-AssertDefining the test structureWorking backward from outcomesIncreasing workflow efficiencyDefining a good testApplying the FIRST principlesUsing one assert per testDeciding on the scope of a unit testCatching common errorsAsserting exceptionsOnly testing public methodsPreserving encapsulationLearning from our testsA messy Arrange stepA messy Act stepA messy Assert stepLimitations of unit testsCode coverage – an often-meaningless metricWriting the wrong testsBeginning WordzSummaryQuestions and answers
Chapter 6: Following the Rhythms of TDD
Technical requirementsFollowing the RGR cycleStarting on redKeep it simple – moving to greenRefactoring to clean codeWriting our next tests for WordzSummaryQuestions and answersFurther reading

Chapter 7: Driving Design – TDD and SOLID
Technical requirementsTest guide – we drive the designSRP – simple building blocksToo many responsibilities make code harder to work withAbility to reuse codeSimplified future maintenanceCounter-example – shapes code that violates SRPApplying SRP to simplify future maintenanceOrganizing tests to have a single responsibilityDIP – hiding irrelevant detailsApplying DI to the shapes codeLSP – swappable objectsReviewing LSP usage in the shapes codeOCP – extensible designAdding a new type of shapeISP – effective interfacesReviewing ISP usage in the shapes codeSummaryQuestions and answers
Chapter 8: Test Doubles – Stubs and Mocks
Technical requirementsThe problems collaborators present for testingThe challenges of testing unrepeatable behaviorThe challenges of testing error handlingUnderstanding why these collaborations are challengingThe purpose of test doublesMaking the production version of the codeUsing stubs for pre-canned resultsWhen to use stub objectsUsing mocks to verify interactionsUnderstanding when test doubles are appropriateAvoiding the overuse of mock objectsDon’t mock code you don’t ownDon’t mock value objectsYou can’t mock without dependency injectionDon’t test the mockWhen to use mock objectsWorking with Mockito – a popular mocking libraryGetting started with MockitoWriting a stub with MockitoWriting a mock with MockitoBlurring the distinction between stubs and mocksArgument matchers – customizing behavior of test doublesDriving error handling code with testsTesting an error condition in WordzSummaryQuestions and answersFurther reading
Chapter 9: Hexagonal Architecture –Decoupling External Systems
Technical requirementsWhy external systems are difficultEnvironmental problems bring troubleAccidentally triggering real transactions from testsWhat data should we expect?Operating system calls and system timeChallenges with third-party servicesDependency inversion to the rescueGeneralizing this approach to the hexagonal architectureOverview of the hexagonal architecture’s componentsThe golden rule – the domain never connects directly to adaptersWhy the hexagon shape?Abstracting out the external systemDeciding what our domain model needsWriting the domain codeDeciding what should be in our domain modelUsing libraries and frameworks in the domain modelDeciding on a programming approachSubstituting test doubles for external systemsReplacing the adapters with test doublesUnit testing bigger unitsUnit testing entire user storiesWordz – abstracting the databaseDesigning the repository interfaceDesigning the database and random numbers adaptersSummaryQuestions and answersFurther reading
Chapter 10: FIRST Tests and the Test Pyramid
Technical requirementsThe test pyramidUnit tests – FIRST testsIntegration testsWhat should an integration test cover?Testing database adaptersTesting web servicesConsumer-driven contract testingEnd-to-end and user acceptance testsAcceptance testing toolsCI/CD pipelines and test environmentsWhat 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 pipelinesTest environmentsTesting in productionWordz – integration test for our databaseFetching a word from the databaseSummaryQuestions and answersFurther reading
Chapter 11: Exploring TDD with Quality Assurance
TDD – its place in the bigger quality pictureUnderstanding the limits of TDDNo more need for manual testing?Manual exploratory – discovering the unexpectedCode review and ensemble programmingUser interface and user experience testingTesting the user interfaceEvaluating the user experienceSecurity testing and operations monitoringIncorporating manual elements into CI/CD workflowsSummaryQuestions and answersFurther reading
Chapter 12: Test First, Test Later, Test Never
Adding tests firstTest-first is a design toolTests form executable specificationsTest-first provides meaningful code coverage metricsBeware of making a code coverage metric a targetBeware of writing all tests upfrontWriting tests first helps with continuous deliveryWe can always test it later, right?Test-later is easier for a beginner to TDDTest-later makes it harder to test every code pathTest-later makes it harder to influence the software designTest-later may never happenTests? They’re for people who can’t write code!What happens if we do not test during development?Testing from the inside outTesting from the outside inDefining test boundaries with hexagonal architectureInside-out works well with the domain modelOutside-in works well with adaptersUser stories can be tested across the domain modelSummaryQuestions and answersFurther reading
Part 3: Real-World TDD
Chapter 13: Driving the Domain Layer
Technical requirementsStarting a new gameTest-driving starting a new gameTracking the progress of the gameTriangulating word selectionPlaying the gameDesigning the scoring interfaceTriangulating game progress trackingEnding the gameResponding to a correct guessTriangulating the game over due to too many incorrect guessesTriangulating response to guess after game overReviewing our designSummaryQuestions and answersFurther reading
Chapter 14: Driving the Database Layer
Technical requirementsInstalling the Postgres databaseCreating a database integration testCreating a database test with DBRiderDriving out the production codeImplementing the WordRepository adapterAccessing the databaseImplementing GameRepositorySummaryQuestions and answersFurther reading
Chapter 15: Driving the Web Layer
Technical requirementsStarting a new gameAdding required libraries to the projectWriting the failing testCreating our HTTP serverAdding routes to the HTTP serverConnecting to the domain layerRefactoring the start game codeHandling errors when starting a gameFixing the unexpectedly failing testsPlaying the gameIntegrating the applicationUsing the applicationSummaryQuestions and answersFurther reading
Index
Why subscribe?
Other Books You May EnjoyPackt is searching for authors like youShare Your ThoughtsDownload a free PDF copy of this book

Content preview from Test-Driven Development with Java

4 Building an Application Using TDD

We’re going to learn the practical side of TDD by building the application test first. We are also going to use an approach known as agile software development as we build. Being agile means building our software in small, self-contained iterations instead of building it all at once. These small steps allow us to learn more about the software design as we go. We adapt and refine the design over time, as we become more certain of how a good design might look. We can offer working functionality to early test users and receive their feedback long before the application is complete. This is valuable. As we have seen in earlier chapters, TDD is an excellent approach for providing rapid feedback on self-contained ...

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: 9781803236230

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Test-Driven Development with Java

by Alan Mellor

4

Building an Application Using TDD

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.