最新章節(jié)

• Leave a review - let other readers know what you think
• Other Books You May Enjoy
• Summary
• This does not have to be the end
• This is just the beginning
• What is next?

• Leave a review - let other readers know what you think 更新時(shí)間：2021-06-24 18:32:33
• Other Books You May Enjoy
• Summary
• This does not have to be the end
• This is just the beginning
• What is next?
• First execution
• Automating builds
• Jenkins installation
• Towards continuous delivery
• Implementing continuous integration
• Increasing test coverage
• Possible improvements
• Conclusions
• Deployments to production
• Release procedure
• Exploring the codebase
• Case study – Awesome Gambling Corp
• Leverage TDD by Implementing Continuous Delivery
• Summary
• Tools
• Development practices
• Processes
• Naming conventions
• Best practices
• TDD in a nutshell
• Putting It All Together
• Summary
• Working with the template engine
• Implementing the Fibonacci service
• A Feature Toggle example
• Feature Toggles
• Continuous integration delivery and deployment
• Feature Toggles – Deploying Partially Done Features to Production
• Summary
• Removing the primitive obsession with status as int
• Adding a new feature
• Parameterizing a constructor
• Extract and override call
• Injecting the BookRepository dependency
• Automating the test cases
• Writing end-to-end test cases
• Applying the legacy code algorithm
• Introducing the new feature
• How to find candidates for refactoring
• Preliminary investigation
• Black-box or spike testing
• Adding a new feature
• Technical comments
• Description
• Legacy kata
• The kata exercise
• Writing tests
• Breaking dependencies
• Finding test points
• Identifying change points
• Applying the legacy code change algorithm
• The legacy code change algorithm
• A lack of dependency injection
• Other ways to recognize legacy code
• Legacy code example
• Legacy code
• Refactoring Legacy Code – Making It Young Again
• Summary
• Final validation
• JBehave steps
• Selenium and Selenide
• Pending steps
• JBehave runner
• JBehave
• The book store BDD story
• Scenarios
• Narrative
• Behavior-driven development
• Documentation for non-coders
• Documentation for coders
• Documentation
• Different specifications
• BDD – Working Together with the Whole Team
• Summary
• reduce
• flatMap
• map
• filter
• Streams
• Requirement – complex operations
• Requirement – single operations
• Requirement – handling invalid input
• Requirements
• Kata – Reverse Polish Notation
• Functions revisited
• Example of Optional
• Optional – dealing with uncertainty
• Setting up the environment
• TDD and Functional Programming – A Perfect Match
• Summary
• The integration test
• Tests separation
• Integration tests
• Exercises
• Implementation
• Specification – alternate players
• Implementation
• Specification – error handling
• Implementation
• Specification – storing current move
• Specification refactoring
• Implementation
• Specification – creating new collection
• Requirement 2 – store every turn
• Implementation
• Specification – error handling
• Implementation
• Specification – drop operation feedback
• Implementation
• Specification – clear state between games
• Implementation
• Specification – error handling
• Refactoring
• Implementation
• Specification – adding operation feedback
• Implementation
• Specification – adding items to the Mongo collection
• Refactoring
• Implementation
• Specification – a name for the Mongo collection
• Implementation
• Specification – DB name
• Requirement 1 – store moves
• Developing Tic-Tac-Toe v2
• Tic-Tac-Toe v2 requirements
• Mockito
• Mock objects
• Terminology
• Why mocks?
• Mocking
• Mocking – Removing External Dependencies
• Summary
• Final considerations
• Requirement 8 – win condition (IV)
• Requirement 7 – win condition (III)
• Requirement 6 – win condition (II)
• Requirement 5 – win condition (I)
• Requirement 4 – the game's output
• Requirement 3 – player shifts
• Requirement 2 – introducing discs
• Requirement 1 – the game's board
• Hamcrest
• The TDD or test-first implementation
• Requirement 8 – win condition (IV)
• Requirement 7 – win condition (III)
• Requirement 6 – win condition (II)
• Requirement 5 – win conditions (I)
• Requirement 4 – the game's output
• Requirement 3 – player shifts
• Requirement 2 – introducing discs
• Requirement 1 – the game's board
• Test-last implementation of Connect 4
• Requirements
• Connect 4
• SOLID principles
• Occam's razor
• Keep it simple stupid
• Don't Repeat Yourself
• You Ain't Gonna Need It
• Design principles
• Why should we care about design?
• Design – If It's Not Testable It's Not Designed Well
• Summary
• Requirement – detecting obstacles
• Implementation
• Specification – dealing with map boundaries
• Refactoring
• Implementation
• Specification – planet information
• Requirement – representing spheric maps
• Implementation
• Specification – combined commands
• Implementation
• Specification – single commands
• Requirement – commands
• Implementation
• Specification – turning right
• Implementation
• Specification – turning left
• Requirement – rotating the ship
• Implementation
• Specification – moving backward
• Implementation
• Specification – moving forward
• Requirement – forward and backward moves
• Refactoring
• Implementation
• Specification – keeping position and direction in memory
• Requirement – starting point and orientation
• Helper classes
• Project setup
• Developing the remote-controlled ship
• Remote-controlled ship requirements
• TestNG versus JUnit summary
• The @Test(expectedExceptions = SomeClass.class) annotation argument
• The @Test(enable = false) annotation argument
• The @BeforeMethod and @AfterMethod annotations
• The @BeforeClass and @AfterClass annotations
• The @BeforeSuite @BeforeTest @BeforeGroups @AfterGroups @AfterTest and @AfterSuite annotations
• The @Test annotation
• TestNG
• Unit testing with TDD
• Why not use unit tests exclusively?
• Code refactoring
• Why unit testing?
• What is unit testing?
• Unit testing
• Unit Testing – Focusing on What You Do and Not on What Has Been Done
• Summary
• More exercises
• Code coverage
• Refactoring
• Implementation
• Test – handling a tie situation
• Requirement 4 – tie conditions
• Refactoring
• Implementation
• Test – winning condition IV
• Implementation
• Test – winning condition III
• Implementation
• Test – winning condition II
• Refactoring
• Implementation
• Test – winning condition I
• Implementation
• Test – by default there's no winner
• Requirement 3 – adding winning conditions
• Test – X plays right after O
• Implementation
• Test – O plays right after X
• Implementation
• Test – X plays first
• Requirement 2 – adding two-player support
• Refactoring
• Implementation
• Test – occupied spot
• Implementation
• Test – board boundaries II
• Implementation
• Test – board boundaries I
• Requirement 1 – placing pieces
• Developing Tic-Tac-Toe
• Tic-Tac-Toe game requirements
• Repeating
• Refactoring
• Running all the tests
• Writing the implementation code
• Running all the tests and confirming that the last one is failing
• Writing a test
• The Red-Green-Refactor process
• Setting up Gradle/Java project in IntelliJ IDEA
• Setting up the environment with Gradle and JUnit
• Red-Green-Refactor – From Failure Through Success until Perfection
• Summary
• Cucumber
• JBehave
• Behavior-driven development
• Selenide
• Selenium
• Web-testing frameworks
• User interface testing
• Extra power for mocks
• EasyMock
• Mockito
• Mocking frameworks
• JaCoCo
• Code coverage tools
• AssertJ
• Hamcrest
• Hamcrest and AssertJ
• TestNG
• JUnit
• Unit-testing frameworks
• The IDEA demo project
• The integrated development environment
• Build tools
• Docker
• Vagrant
• Virtual machines
• Git
• Tools Frameworks and Environments
• Summary
• No debugging
• Executable documentation
• Mocking
• Better tests
• The difference between quality checking and quality assurance
• White-box testing
• Black-box testing
• Testing
• It's not about testing
• Speed is the key
• Red-Green-Refactor
• Understanding TDD
• Why TDD?
• Why Should I Care for Test-Driven Development?
• Reviews
• Get in touch
• Conventions used
• Download the color images
• Download the example code files
• To get the most out of this book
• What this book covers
• Who this book is for
• Preface
• Packt is searching for authors like you
• About the reviewer
• About the authors
• Contributors
• PacktPub.com
• Why subscribe?
• Packt Upsell
• Title Page
• coverpage

• coverpage
• Title Page
• Packt Upsell
• Why subscribe?
• PacktPub.com
• Contributors
• About the authors
• About the reviewer
• Packt is searching for authors like you
• Preface
• Who this book is for
• What this book covers
• To get the most out of this book
• Download the example code files
• Download the color images
• Conventions used
• Get in touch
• Reviews
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• Putting It All Together
• TDD in a nutshell
• Best practices
• Naming conventions
• Processes
• Development practices
• Tools
• Summary
• 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
• Leave a review - let other readers know what you think 更新時(shí)間：2021-06-24 18:32:33