Test-Driven Java Development - Invoke TDD principles for end-to-end application development, 2nd Ed, (true pdf)

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