[DevDay 2016] Real Unit Testing with mocking framework - Speaker: Phat Vu – Scrum Master at Axon Active Vietnam
Why do programmers hate writing Unit Tests? One big reason is object dependency. An object under testing may have dependencies on other complex objects, which might not have been implemented or been complicated when invoking.
Join the session refresh your thinking about Unit Testing and overview of mocking framework, as well as learn some practice/gotcha to write a real Unit Test, how to isolate the behavior of the object you want to test, how to simulate the behavior of the dependencies.
Speaker: Phat Vu – Scrum Master at Axon Active Vietnam
Vũ Hồng Phát
Software Engineer, 05 years
Java, Database, Open-source
• High quality software development
• Do you know what’s unit testing?
• Do you think it’s important?
• Who will write it?
• Do you enjoy when writing it?
Unit testing is a software development process in which the
smallesttestable parts of an application, called units, are
individually and independently scrutinized for proper operation.
Unit testing is often automated but it can also be done manually.
1. Prove that your code actually works.
2. Form of sample code / documentation
3. Code refactoring
4. Forces you to plan before you code
• Better design
• Testable code
5. Integrate with Continuous Integration
6. It’s more fun to code with them than without
UNIT TEST FIRST?
• A tested object usually talks to other objects known as
collaborators / dependencies
• These dependencies need to be created, so the tested
object can be assigned to them in the test
• Any hello world has no dependencies on outside classes
• In the real world, software has dependencies
REAL UNIT TESTING
• The idea of unit testing is that we want to test our code
without testing the dependencies
• Unit testing verifies that the code being tested works,
regardless of it's dependencies
• Be able to test the code, no matter dependencies
• If the code I write works as designed and my dependencies
work as designed, then they should work together as designed
MathService has dependency : Calculator
When testing MathService:
• Do not test Calculator implementation.
Assume they has been tested and works as designed
• Do not wait for their implementation
In OOP, mock objects are simulated objects that mimic
the behavior of real objects in controlled ways.
CRASH TEST DUMMY
GIVEN – WHEN - THEN
Style of representing tests, part of BDD
• Given defines the preconditions that hold before an
event or operation
• When identifies an event or operation
• Then identities the post conditions that hold after
the event or operation
GIVEN – WHEN - THEN
• Given : the Login page is opening
• When : I enter a correct user name & password, then
click on Login button
• Then : I am on the Home page
Is a mocking framework helpful in creating mocks
and spies in a simple and intuitive way, while at the same
time providing great control of the whole process
“Really cleans up the unit test by not requiring expectations.
Personally, I much prefer the Mockito API to the EasyMock API
for that reason” - Hamlet D'Arcy
How can I test MathService.add() without concern on its
dependency (Calculator implementation) ?
I have to simulate Calculator as a mock object
@Mock - create a mock object
must initialize this object with a MockitoAnnotations.initMocks(this)
@InjectMocks - injects mocks into tested object automatically
Return different values for subsequent calls of the same method
• A mock created as a proxy to an existing real object
• Some methods can be stubbed
• Some ones invoked in real
• Partial mocking
• Usually there is no reason (code smell) to spy on real objects
Mockito can not:
• mock final classes
• mock enums
• mock final methods
• mock static methods
• mock private methods
• mock hashCode() and equals()
PowerMock or JMockit can be used to work with code that
cannot be mocked with pure Mockito
A measurement of how many lines/blocks of your code are executed
while the automated tests are running
A useful tool for finding untested parts of a codebase
100% - it would smell of someone writing tests to make the coverage
numbers happy, but not thinking about what they are doing
Low coverage numbers, are a sign of trouble. But high numbers
don't necessarily mean much
Upper 80s or 90s
MOCK PRIVATE METHODS
• Low cohesion (has too many responsibilities)
• Extract into separate class.
Workaround Using Mockito
• Changing private access modifier to default
• Partially mock testing object by using spy
• PowerMock or JMockIt
(More : https://dzone.com/articles/mock-private-method)
Unit testing is testing units
Units bare without dependencies.
And this can be done with mocks
SAYING IT SIMPLY