Test-Driven Java Development, Second Edition : Invoke TDD Principles for End-To-end Application Development, 2nd Edition.

Cover -- Title Page -- Copyright and Credits -- Packt Upsell -- Contributors -- Table of Contents -- Preface -- Chapter 1: Why Should I Care for Test-Driven Development? -- Why TDD? -- Understanding TDD -- Red-Green-Refactor -- Speed is the key -- It's not about testing -- Testing -- Black-box testing -- White-box testing -- The difference between quality checking and quality assurance -- Better tests -- Mocking -- Executable documentation -- No debugging -- Summary -- Chapter 2: Tools, Frameworks, and Environments -- Git -- Virtual machines -- Vagrant -- Docker -- Build tools -- The integrated development environment -- The IDEA demo project -- Unit-testing frameworks -- JUnit -- TestNG -- Hamcrest and AssertJ -- Hamcrest -- AssertJ -- Code coverage tools -- JaCoCo -- Mocking frameworks -- Mockito -- EasyMock -- Extra power for mocks -- User interface testing -- Web-testing frameworks -- Selenium -- Selenide -- Behavior-driven development -- JBehave -- Cucumber -- Summary -- Chapter 3: Red-Green-Refactor - From Failure Through Success until Perfection -- Setting up the environment with Gradle and JUnit -- Setting up Gradle/Java project in IntelliJ IDEA -- The Red-Green-Refactor process -- Writing a test -- Running all the tests and confirming that the last one is failing -- Writing the implementation code -- Running all the tests -- Refactoring -- Repeating -- Tic-Tac-Toe game requirements -- Developing Tic-Tac-Toe -- Requirement 1 - placing pieces -- Test - board boundaries I -- Implementation -- Test - board boundaries II -- Implementation -- Test - occupied spot -- Implementation -- Refactoring -- Requirement 2 - adding two-player support -- Test - X plays first -- Implementation -- Test - O plays right after X -- Implementation -- Test - X plays right after O -- Requirement 3 - adding winning conditions -- Test - by default there's no winner.

Implementation -- Test - winning condition I -- Implementation -- Refactoring -- Test - winning condition II -- Implementation -- Test - winning condition III -- Implementation -- Test - winning condition IV -- Implementation -- Refactoring -- Requirement 4 - tie conditions -- Test - handling a tie situation -- Implementation -- Refactoring -- Code coverage -- More exercises -- Summary -- Chapter 4: Unit Testing - Focusing on What You Do and Not on What Has Been Done -- Unit testing -- What is unit testing? -- Why unit testing? -- Code refactoring -- Why not use unit tests exclusively? -- Unit testing with TDD -- TestNG -- The @Test annotation -- The @BeforeSuite, @BeforeTest, @BeforeGroups, @AfterGroups, @AfterTest, and @AfterSuite annotations -- The @BeforeClass and @AfterClass annotations -- The @BeforeMethod and @AfterMethod annotations -- The @Test(enable = false) annotation argument -- The @Test(expectedExceptions = SomeClass.class) annotation argument -- TestNG versus JUnit summary -- Remote-controlled ship requirements -- Developing the remote-controlled ship -- Project setup -- Helper classes -- Requirement - starting point and orientation -- Specification - keeping position and direction in memory -- Implementation -- Refactoring -- Requirement - forward and backward moves -- Specification - moving forward -- Implementation -- Specification - moving backward -- Implementation -- Requirement - rotating the ship -- Specification - turning left -- Implementation -- Specification - turning right -- Implementation -- Requirement - commands -- Specification - single commands -- Implementation -- Specification - combined commands -- Implementation -- Requirement - representing spheric maps -- Specification - planet information -- Implementation -- Refactoring -- Specification - dealing with map boundaries -- Implementation.

Requirement - detecting obstacles -- Summary -- Chapter 5: Design - If It's Not Testable, It's Not Designed Well -- Why should we care about design? -- Design principles -- You Ain't Gonna Need It -- Don't Repeat Yourself -- Keep it simple, stupid -- Occam's razor -- SOLID principles -- Connect 4 -- Requirements -- Test-last implementation of Connect 4 -- Requirement 1 - the game's board -- Requirement 2 - introducing discs -- Requirement 3 - player shifts -- Requirement 4 - the game's output -- Requirement 5 - win conditions (I) -- Requirement 6 - win condition (II) -- Requirement 7 - win condition (III) -- Requirement 8 - win condition (IV) -- The TDD or test-first implementation -- Hamcrest -- Requirement 1 - the game's board -- Requirement 2 - introducing discs -- Requirement 3 - player shifts -- Requirement 4 - the game's output -- Requirement 5 - win condition (I) -- Requirement 6 - win condition (II) -- Requirement 7 - win condition (III) -- Requirement 8 - win condition (IV) -- Final considerations -- Summary -- Chapter 6: Mocking - Removing External Dependencies -- Mocking -- Why mocks? -- Terminology -- Mock objects -- Mockito -- Tic-Tac-Toe v2 requirements -- Developing Tic-Tac-Toe v2 -- Requirement 1 - store moves -- Specification - DB name -- Implementation -- Specification - a name for the Mongo collection -- Implementation -- Refactoring -- Specification - adding items to the Mongo collection -- Implementation -- Specification - adding operation feedback -- Implementation -- Refactoring -- Specification - error handling -- Implementation -- Specification - clear state between games -- Implementation -- Specification - drop operation feedback -- Implementation -- Specification - error handling -- Implementation -- Requirement 2 - store every turn -- Specification - creating new collection -- Implementation -- Specification refactoring.

Specification - storing current move -- Implementation -- Specification - error handling -- Implementation -- Specification - alternate players -- Implementation -- Exercises -- Integration tests -- Tests separation -- The integration test -- Summary -- Chapter 7: TDD and Functional Programming - A Perfect Match -- Setting up the environment -- Optional - dealing with uncertainty -- Example of Optional -- Functions revisited -- Kata - Reverse Polish Notation -- Requirements -- Requirement - handling invalid input -- Requirement - single operations -- Requirement - complex operations -- Streams -- filter -- map -- flatMap -- reduce -- Summary -- Chapter 8: BDD - Working Together with the Whole Team -- Different specifications -- Documentation -- Documentation for coders -- Documentation for non-coders -- Behavior-driven development -- Narrative -- Scenarios -- The book store BDD story -- JBehave -- JBehave runner -- Pending steps -- Selenium and Selenide -- JBehave steps -- Final validation -- Summary -- Chapter 9: Refactoring Legacy Code - Making It Young Again -- Legacy code -- Legacy code example -- Other ways to recognize legacy code -- A lack of dependency injection -- The legacy code change algorithm -- Applying the legacy code change algorithm -- Identifying change points -- Finding test points -- Breaking dependencies -- Writing tests -- The kata exercise -- Legacy kata -- Description -- Technical comments -- Adding a new feature -- Black-box or spike testing -- Preliminary investigation -- How to find candidates for refactoring -- Introducing the new feature -- Applying the legacy code algorithm -- Writing end-to-end test cases -- Automating the test cases -- Injecting the BookRepository dependency -- Extract and override call -- Parameterizing a constructor -- Adding a new feature -- Removing the primitive obsession with status as int.

Summary -- Chapter 10: Feature Toggles - Deploying Partially Done Features to Production -- Continuous integration, delivery, and deployment -- Feature Toggles -- A Feature Toggle example -- Implementing the Fibonacci service -- Working with the template engine -- Summary -- Chapter 11: Putting It All Together -- TDD in a nutshell -- Best practices -- Naming conventions -- Processes -- Development practices -- Tools -- Summary -- Chapter 12: Leverage TDD by Implementing Continuous Delivery -- Case study - Awesome Gambling Corp -- Exploring the codebase -- Release procedure -- Deployments to production -- Conclusions -- Possible improvements -- Increasing test coverage -- Implementing continuous integration -- Towards continuous delivery -- Jenkins installation -- Automating builds -- First execution -- What is next? -- This is just the beginning -- This does not have to be the end -- Summary -- Other Books You May Enjoy -- Index.

Test-driven development relies on a test-first procedure that emphasizes writing a test before the code, and then refactoring the code to optimize it. Performing TDD with Java improves the productivity of programmers and maintainability and performance of code. It also develops a deeper understanding of the language and shows how to employ it.

Description based on publisher supplied metadata and other sources.

Electronic reproduction. Ann Arbor, Michigan : ProQuest Ebook Central, 2024. Available via World Wide Web. Access may be limited to ProQuest Ebook Central affiliated libraries.