We did not use code coverage tools throughout this exercise. The reason is that we wanted you to be focused on the red-green-refactor model. You wrote a test, saw it fail, wrote the implementation code, saw that all the tests were executed successfully, refactored the code whenever you saw an opportunity to make it better, and then you repeated the process. Did our tests cover all cases? That's something that code coverage tools such as JaCoCo can answer. Should you use those tools? Probably, only in the beginning. Let me clarify that. When you are starting with TDD, you will probably miss some tests or implement more than what the tests defined. In those cases, using code coverage is a good way to learn from your own mistakes. Later on, the more experienced you become with TDD, the less of a need you'll have for such tools. You'll write tests and just enough of the code to make them pass. Your coverage will be high with or without tools such as JaCoCo. There will be a small...
Test-Driven Java Development
Test-Driven Java Development
Overview of this book
Table of Contents (17 chapters)
Test-Driven Java Development
Credits
About the Authors
About the Reviewers
www.PacktPub.com
Preface
Free Chapter
Why Should I Care for Test-driven Development?
Tools, Frameworks, and Environments
Red-Green-Refactor – from Failure through Success until Perfection
Unit Testing – Focusing on What You Do and Not on What Has Been Done
Design – If It's Not Testable, It's Not Designed Well
Mocking – Removing External Dependencies
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
Index
Customer Reviews