舉報 
會員
Test-Driven Java Development（Second Edition）
Ifyou'reanexperiencedJavadeveloperandwanttoimplementmoreeffectivemethodsofprogrammingsystemsandapplications,thenthisbookisforyou.
目錄(321章)
倒序
- 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 更新時間：2021-06-24 18:32:33
推薦閱讀
- 案例式C語言程序設計
- JavaScript語言精髓與編程實踐（第3版）
- PyTorch自然語言處理入門與實戰
- DevOps入門與實踐
- Mastering Ubuntu Server
- MySQL數據庫管理與開發（慕課版）
- Nexus規模化Scrum框架
- 大學計算機基礎（第2版）（微課版）
- Scala編程（第5版）
- Visual Studio Code 權威指南
- Mastering VMware Horizon 7（Second Edition）
- Hands-On Dependency Injection in Go
- 實戰Python網絡爬蟲
- Web前端開發最佳實踐
- SQL Server 2008實用教程（第3版）
- Spring Boot學習指南：構建云原生Java和Kotlin應用程序
- Mastering High Performance with Kotlin
- HTML 5與CSS 3權威指南（第4版·下冊）
- Learning Adobe Muse
- AngularJS Directives Cookbook
- Kotlin for Enterprise Applications using Java EE
- 你不知道的JavaScript（下卷）
- Java程序設計經典300例
- AR界面設計
- Sass Essentials
- Learning iPhone Game Development with Cocos2D 3.0
- Visual Basic程序設計教程（第3版）
- 微服務中臺架構開發
- Power BI數據分析：報表設計和數據可視化應用大全
- 軟件靈活性設計：如何避免陷入編程困境
