舉報 
會員
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
推薦閱讀
- ExtGWT Rich Internet Application Cookbook
- Mastering Adobe Captivate 2017（Fourth Edition）
- 區塊鏈架構與實現：Cosmos詳解
- Spring Boot企業級項目開發實戰
- Serverless computing in Azure with .NET
- RealSenseTM互動開發實戰
- 用戶體驗可視化指南
- Zabbix Performance Tuning
- Distributed Computing in Java 9
- Vue.js光速入門及企業項目開發實戰
- Spring Data JPA從入門到精通
- Java EE項目應用開發
- 計算機應用基礎（Windows 7+Office 2010）
- Google Maps JavaScript API Cookbook
- Learning NHibernate 4
- 面向對象程序設計及C++實驗指導（第3版）
- jMonkeyEngine 3.0 Cookbook
- 深入解析WPF編程
- 常用工具軟件（第4版）
- 架構真意：企業級應用架構設計方法論與實踐
- Mastering the Nmap Scripting Engine
- Web Penetration Testing with Kali Linux（Second Edition）
- Creative Projects for Rust Programmers
- Mastering FreeSWITCH
- Python Machine Learning By Example
- Unity3D網絡游戲實戰（第2版）
- Exploring Data with RapidMiner
- 深入學習Java開發簡單應用（藍橋杯軟件大賽培訓教材-Java方向）
- OpenShift云原生架構：原理與實踐
- Python從入門到精通（第2版）
