Journey to unit testing

1. Journey to Unit Testing : A Lesson
Learned
Avicienna Ulhaq
@noxymon

2. Workin’ Ground Truth!

3. Program testing can be used
to show the presence of
bugs, but never to show
their absence!
(Dijkstra, 1970)
Edsger W. Dijkstra (1930 - 2002)
Notes on Structured Programming, Technological
University Eindhoven

4. Why ?

5. Rotten Code
Write-Ignore-Rot

6. Beck, Kent. 2 Hat Of Developer
Refactoring
When you're wearing the refactoring
hat, every change you make
preservers observable behavior,
keeps the tests green, and allows you
to make many small changes without
going near a debugger.
Adding function.
When you add function, however,
things are more open ended as you
will add tests and break existing
tests. The adding function hat is
more stressful and riskier, so it's
nice to wear the refactoring hat as
much as possible.

7. “All code is guilty until
proven it innocent”

8. Key of Agile Development
The heart of Scrum is a Sprint, a time-box of one month or less during
which a "Done", useable, and potentially releasable product
Increment is created.
(Shuterland and Schwaber)

9. What ?

10. It’s a Tools

11. Level of Testing
Does the whole system work?
Does our code work against
code we can’t change?
Do our objects do the right
thing, are they convenient to
work with?

12. How ?

13. Single Responsibility Principle
A class should have only one reason to change.

14. Function Always Do One Thing
Functions should do one thing. They should do it well. They should do it only.
Abstrak

15. Function Always Do One Thing
VIOLATESALLOWED

16. Dependecy Injection
Setup of dependency, is responsibility of the caller. Not The Dependent.
OrderService
DriverOjek
+ saveTarif()
<<use>>
DB
OrderService DriverOjek

17. Example :
Not Testable
Testable

18. Mocking Tools
mock objects are simulated objects that mimic the
behavior of real objects in controlled ways
● Verify behavior
● Mimic behavior

19. Use the DI Trick

20. Verify the behavior

21. FIRST Principle
● [F]ast ‒ imagine, every you stroke ctrl+s
● [I]solated ‒ avoid dependency to other unit test
● [R]epeatable ‒ it’s not truth, if not constant
● [S]elf-Validating ‒ avoid manual thing: setup, verification
● [T]imely ‒ later means never

22. Mimic the behavior

23. Mimic the behavior

24. Right Are the results right
B Are all the boundary conditions correct
I Can you check inverse relationship
C Can you cross-check result using others means
?
E Can you force error conditions to happen ?
P Are performance characteristics within bounds
?
Right-BICEP

25. 3 Laws of TDD*
1. You are not allowed to write any
production code unless it is to make a
failing unit test pass.
2. You are not allowed to write any more
of a unit test than is sufficient to fail;
and compilation failures are failures.
3. You are not allowed to write any more
production code than is sufficient to
pass the one failing unit test.
*iya, emang susah.

26. Further Reading
● Clean Code by Robert C Martin
● Pragmatic Unit Testing in Java 8 with JUnit by Jeff
Langr
● Google Clean Code Talks,
https://www.youtube.com/watch?v=wEhu57pih5w
● Three Laws of TDD,
https://www.youtube.com/watch?v=qkblc5WRn-U
● Uncle Bob Test Workshop,
https://www.youtube.com/watch?v=K7yR--yL0bc

27. Happy Code !