Jump to ratings and reviews
Rate this book

Test-Driven Development with Mockito

Rate this book
Test-Driven Development with Mockito

172 pages, Paperback

First published January 1, 2013

1 person is currently reading
10 people want to read

About the author

Sujoy Acharya

6 books1 follower

Ratings & Reviews

What do you think?
Rate this book

Friends & Following

Create a free account to discover what your friends think of this book!

Community Reviews

5 stars
2 (16%)
4 stars
3 (25%)
3 stars
2 (16%)
2 stars
2 (16%)
1 star
3 (25%)
Displaying 1 - 3 of 3 reviews
2 reviews
August 13, 2018
Kent Beck is the originator of Extreme Programming and TDD.
http://en.wikipedia.org/wiki/Kent_Beck

TDD gives us the following benefits:
• Clean, testable, and maintainable code.
• Another benefit to incrementally building your code is that your API is easier to work with
• tests are written to provide enough documentation of code.
• You are trying to break your own code as soon as possible.
• You should also avoid over engineering the class that you are writing. Just write what's needed to make all tests green.

Steps:
• Add a Test
• Write Code to Pass the test
• Refactor and Apply Design

Refactoring is a series of small steps to change the internal structure of code without altering its external behavior. Refactoring is applied to make the code readable, maintainable, and clean.

Reasons behind refactoring:
• Easy to add new features/code:
• Improves the design of the existing code: Open/closed (open for extension but closed for modification), DRY ( Don't Repeat Yourself), and YAGNI (You Aren't Gonna Need It).
• Improves readability and understanding

When not to refactor:
• Code does not work,
• Not enough tests,
• Rewrite: When the code is too fragile! We need to estimate which one is easier: rewrite or refactor?

Stopping refactoring:
• All tests are green
• Class and method names are meaningful
• No code duplication (the code uses the smallest number of classes and methods)
• Each class is doing its own work; if needed, it delegates work to other classes
• No bidirectional dependencies—A > B and B > A
• Moreover, the code expresses the purpose
• Finally, adding a new feature is not causing cascading changes in all layers/modules

Comments
"Don't comment bad code – rewrite it."

Unit tests should adhere to the following rules:
• Order independent and isolated: The test class ATest.java should not be dependent on the output of the test class BTest.java, or the test shouldn't fail if BTest.java is executed after ATest.java
• Trouble-free setup and run: Unit tests should not require DB connection or Internet connection or clean up temp directory
• Effortless execution: Unit tests should not be "It works fine on Server abc but doesn't run on my local"
• Formula 1 execution: A test should not take more than a second to finish the execution

Replacing conditional logic with command
replace if-else-if with map of key-commands or just strategy (passed by constructor)

If a code is dependent on database access, it is not possible to unit test the code unless the database is available, or if my code needs to send information to a printer and my machine is not connected to LAN

Mockito plays a key role to mock out external dependencies. It mocks out database connection or any external I/O behavior so that the actual logic can be unit tested.
1 review
May 8, 2016
The book was a bit difficult to read due to the discrepencies throughout the book. The first chapter, for example, speaks to testing a tax calculator with 3 rules regarding ranges of money in USD but then the test method name contains 5Lacs. The book also gives you instructions for Eclipse and using certain shortcut key combinations. These key combinations don't work on a Mac.
45 reviews2 followers
May 15, 2015
if you use tdd and want to write more readable test through mockito,and you are new to mockito,it's worth reading
Displaying 1 - 3 of 3 reviews

Can't find what you're looking for?

Get help and learn more about the design.