Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Test-Driven Java Development

You're reading from   Test-Driven Java Development Invoke TDD principles for end-to-end application development with Java

Arrow left icon
Product type Paperback
Published in Aug 2015
Publisher Packt
ISBN-13 9781783987429
Length 284 pages
Edition 1st Edition
Languages
Arrow right icon
Toc

Table of Contents (12) Chapters Close

Preface 1. Why Should I Care for Test-driven Development? 2. Tools, Frameworks, and Environments FREE CHAPTER 3. Red-Green-Refactor – from Failure through Success until Perfection 4. Unit Testing – Focusing on What You Do and Not on What Has Been Done 5. Design – If It's Not Testable, It's Not Designed Well 6. Mocking – Removing External Dependencies 7. BDD – Working Together with the Whole Team 8. Refactoring Legacy Code – Making it Young Again 9. Feature Toggles – Deploying Partially Done Features to Production 10. Putting It All Together Index

Mocking

In order for tests to run fast and provide constant feedback, code needs to be organized in such a way that the methods, functions, and classes can be easily replaced with mocks and stubs. A common word for this type of replacements of the actual code is test double. Speed of the execution can be severely affected with external dependencies; for example, our code might need to communicate with the database. By mocking external dependencies, we are able to increase that speed drastically. Whole unit tests suite execution should be measured in minutes, if not seconds. Designing the code in a way that it can be easily mocked and stubbed, forces us to better structure that code by applying separation of concerns.

More important than speed is the benefit of removal of external factors. Setting up databases, web servers, external APIs, and other dependencies that our code might need, is both time consuming and unreliable. In many cases, those dependencies might not even be available. For example, we might need to create a code that communicates with a database and have someone else create a schema. Without mocks, we would need to wait until that schema is set.

Tip

With or without mocks, the code should be written in a way that we can easily replace one dependency with another.

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image