When you have to make a change in a legacy codebase, here is an algorithm you can use:
- Identify change points
- Find test points
- Break dependencies
- Write tests
- Make changes and refactor
The legacy code change algorithm
by Viktor Farcic, Alex Garcia
Test-Driven Java Development - Second Edition
- Title Page
- Copyright and Credits
- Packt Upsell
- Contributors
- Preface
- Why Should I Care for Test-Driven Development?
- Tools, Frameworks, and Environments
- Red-Green-Refactor – From Failure Through Success until Perfection
- Setting up the environment with Gradle and JUnit
- The Red-Green-Refactor process
- Tic-Tac-Toe game requirements
- Developing Tic-Tac-Toe
- Requirement 1 – placing pieces
- Requirement 2 – adding two-player support
- 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
- Code coverage
- More exercises
- Summary
- Unit Testing – Focusing on What You Do and Not on What Has Been Done
- Unit testing
- 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
- Requirement – detecting obstacles
- Summary
- Design – If It's Not Testable, It's Not Designed Well
- Why should we care about design?
- Connect 4
- 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
- Mocking – Removing External Dependencies
- Mocking
- 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
- Requirement 1 – store moves
- Integration tests
- Summary
- TDD and Functional Programming – A Perfect Match
- BDD – Working Together with the Whole Team
- Refactoring Legacy Code – Making It Young Again
- Feature Toggles – Deploying Partially Done Features to Production
- Putting It All Together
- Leverage TDD by Implementing Continuous Delivery
- Other Books You May Enjoy
The legacy code change algorithm
-
No Comment
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.