Talk @Carmudi GmbH office on Unit testing basics and advanced concepts, like Arrange-Act-Assert rule, Unit Test anatomy, etc. In the end - a small overview of Test Driven Development.

1. Unit Testing: the Clean
Tests
by Serge Kukharev

2. Unit tests are:
• testing one small unit of code at a time
• isolated from the other code
• fast
• clean
• the form of documentation
• as important as the code itself

3. Unit tests are NOT:
• Integration tests (violates speed and isolation rules
of unit tests)
• Functional tests (violates speed and scope rules)

4. Unit Testing benefits
• Helps to be sure about code changes
• Helps to prevent bugs
• Improves QA speed
• Reduces technical dept
• Leads to better design

5. –Kent Beck
“Tests are the Programmer’s stone, transmuting
fear into boredom.”

6. One Unit at a time
• One of the most important rules of unit testing.
• In scope of a test case means, that the small(est) unit of code is tested:
• preferably only one class at a time
• sometimes group of classes is OK, if you can call them as one single
“unit”
• In scope of single test, unit means one method.
• This rule helps to be sure that specific unit works properly, as designed.
• Makes the tests very fast.

7. Test Isolation

8. Dummy
does nothing, helps run the tests

9. Stub
Allows to inject desired input for specific test

10. Spy
Allows us to spy on the dependencies
(should be used very carefully, leads to implementation coupling)

11. Fake
Allows to simulate behaviour.
Often useful outside of the tests.

12. Mock
Allows to set dependency behaviour dynamically.
Can act as spy, fake, stub or dummy.

13. Two styles of Unit
Testing

14. Classical
Focused on testing class with all dependencies.
t for dependencies are used mostly, and only dependencies like

15. Classical Pros
• Easier to write
• Less coupling on the implementation
• Less supportive code
• Easier to make cleaner.

16. Classical Cons
• Ofter tests more than one Unit
• Duplicate tests
• Not always fast
• Problems with dependencies of dependencies
• Only applicable when application has proper
layers

17. Mockist
Every dependency is mocked.

18. Mockist Pros
• Allows to write True Unit tests.
• Allows full control over the dependencies.
• Usually is faster.
• Improves test isolation, leading to easier
bug finding.

19. Mockist Cons
• Sometimes couples you on the implementation.
• More supportive code.
• Test will fail more often when refactoring.

20. So, what to choose?
Anything will work, pick what you like more.

21. Anything 3rd party should be
mocked
• DB classes
• File system calls
• API calls
• etc.
• External library classes
• even framework

22. PHPUnit TestSuit
anatomy
• TestCase consists of 1 or more tests.
• setUp method is used for arranging
shared data
• tearDown used for cleanup
• dataProviders are used to one test
multiple times with different data
each time
• Custom assertements improve
readability and bug detection
• Other private methods used to
improve readability and code reuse.

23. Data Providers
• Used to run the same test with
multiple different datasets.
• Can simplify things
• Can make things worse
• I prefer to avoid them

24. Clean Code in Unit Tests
• Clean tests are as much important as Clean Code itself.
• Reasons:
• Tests are part of code base.
• Test are at least as much important as the code itself.
• Tests are documentation.
• Bad smells in tests can lead to maintenance costs of
supporting those tests.

25. Arrange, Act, Assert rule
• This is advanced rule, that helps to
write Clean Tests
• Every test may consist of 3 parts
• Every part should be in specific order
• First you arrange your test. You define
behaviour of your dependencies.
• Next, you actually call the behaviour
you are testing.
• Finally, you make assortments on that
behaviour.
• This simple rule leads to much cleaner
and readable tests.

26. Custom Assertments
• Writing custom assertments lead to reusable test code
pieces.
• It helps be more specific about what have failed. Compare
this two messages:
• “Test failed asserting true is false”
• “Test failed asserting that SupplierConfig is instance of
CarConfig”
• This might look like extra work, but in fact it isn’t - PHPStorm
automated refactoring can help you do this in 30 seconds.

27. TDD: The Next Step

28. • Test Driven Development is the next step.
• Most people think that writing tests is TDD. That’s
wrong.
• TDD main principle says “You are not allowed to
write production code without writing a failing unit
test first”.

29. • TDD assures that all written code is covered with
tests.
• TDD leads to much better design.
• TDD is more productive.
• TDD leads to a much bigger amount of tests.
• TDD leads to a much better quality of tests.

30. TDD: How it works

31. • TDD has three main steps - Red, Green, Refactor
• In the Red phase you write a minimal specific failing test.
• In the Green phase you implement it.
• In the Refactoring phase you see how you can improve
existing code.
• “Refactoring - to restructure software […] without
changing the observable behavior of the software.” - Kent
Beck

32. • You continue on, by adding more failing tests.
• The more you write your tests, the less specific they
are.
• “As the tests get more specific, the code gets more
generic.” - Robert Martin

33. TDD: Myths

34. • TDD is slow.
• Managers won’t allow it.
• Programmers aren’t testers.
• TDD is too hard.

35. Unit Testing resources
• “Test Driven Development: by Example” by Kent
Beck
• “Refactoring” by Martin Fowler
• Clean Code video series by Robert Martin (aka
Uncle Bob). Ep. #6, 19, 20, 21, 22, 23

36. Thank you!
(please give me your feedback, it is really important for me)
(c) Serge Kukharev 2015