book

Test-Driven Development with Java

by Alan Mellor

January 2023

Intermediate to advanced

348 pages

8h 29m

English

Packt Publishing

Read now

Unlock full access

ContributorsAbout the authorAbout the reviewers
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
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
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
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
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
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
Technical requirementsFollowing the RGR cycleStarting on redKeep it simple – moving to greenRefactoring to clean codeWriting our next tests for WordzSummaryQuestions and answersFurther reading

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
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
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
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
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
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
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
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
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
Other Books You May EnjoyPackt is searching for authors like youShare Your ThoughtsDownload a free PDF copy of this book

Overview

Learn how to master Test-Driven Development (TDD) and elevate your Java programming skills to a new level. In this book, you will explore effective strategies for writing tests first to guide code design, reduce defects, and build maintainable projects using SOLID principles and hexagonal architecture.

What this Book will help me do

Write effective and meaningful test cases in Java.
Understand and adopt TDD principles and rhythms like red-green-refactor.
Elevate code quality through refactoring and strong design principles such as SOLID.
Gain the skills necessary to design robust APIs and manage dependencies using hexagonal architecture.
Learn to tackle real-world challenges by applying TDD in professional environments.

Author(s)

Alan Mellor is an experienced Java developer with a passion for clean code and maintainable software practices. Over his career, he has implemented Test-Driven Development in countless projects, helping teams transform their development processes. With a clear and engaging teaching style, Alan is dedicated to providing practical and actionable guidance to Java professionals.

Who is it for?

This book is perfect for experienced Java developers looking to adopt Test-Driven Development to improve their coding practices. It is designed for individuals who already understand Java and wish to implement more organized workflows. Practitioners seeking to increase the design quality of their software and write robust, error-free code will find this resource invaluable.