Best practices to write testable code in an object oriented programming language. The examples are written in java and junit.

1. Write testable code
best practices and common smells

2. Why you should invest time to write testable code
Testable code is easy to
maintain on the long run
Easy to test code makes the maintenance
straightforward for developers and cheap for
the stakeholders
Coding with testability in mind will drive the
code towards a flexible design, that allows
safe refactoring
2
You will write tests also
after the main release
Most projects deliver software first,
without a full test coverage
Unit tests are added also later, during
consolidation phases, every time you fix a
bug, or you implement a change request
Most likely other developers will also
extend and test your code

3. I am Marian Wamsiedel
I work as a java developer
mainly in java enterprise
projects
You can find me at
marian.wamsiedel@gmail.com
3HELLO!

4. What makes your code easy to test
Loose
coupling No static
calls
4
Logic free
constructors
Compact
data
creation
Clear intent

5. What makes your code easy to test
Loose
coupling No static
calls
5
Logic free
constructors
Compact
data
creation
Clear intent

6. Ensure components loose coupling
Hard coupling severely damages testability

7. Loose coupling
➢
Replace creation of new objects with
dependency injection
➢
Inject all collaborators in the constructor
➢
If forced by the api, create fake constructors
visible from the unit tests
➢
Handle the bloated constructors nicely
7

8. Loose coupling, dependency injection instead of objects creation
● Each unit test will also create a “real” object if the
productive code instantiates a collaborator
● The object creation is a potential slow operation
● A created collaborator can not be faked (mocked,
or stubbed) in the test
8

9. Loose coupling, dependency injection instead of objects creation
● In order to simulate the collaborators behavior, the
tests are forced to fake second/third level
collaborators, or to set up values in a database
● The system dependencies are not transparent.
They are hidden in the implementation, not
declared in the public API
● Replace each “new” call with dependency injection
9

10. Loose coupling, dependency injection instead of objects creation
● The simple knowledge of second level
collaborators disqualifies the test as “unit test”
● If the productive code instantiates a logic class,
like a calculator, the tests will check the behavior
of both classes, mixing the concepts
● Changes in the collaborator's behavior can break
also the main class tests, leading to brittle tests
10

11. Loose coupling, dependency injection instead of objects creation
● Example – instantiated collaborator
public int averageCustomersAge(){
return new CustomerRepository().customers().stream()
.mapToInt(Customer::age)
.average().orElse(0d);}
● The unit test should now fake the result of the
call: new CustomerRepository().customers(),
which requires know how about customer
repository collaborators
11

12. Loose coupling, dependency injection instead of objects creation
● Example – injected collaborator
class CustomerLogic {
private final CustomerRepository repository;
CustomerLogic(final CustomerRepository customerRepository){
this.repository = customerRepository;}
int averageCustomersAge(){
return repository.customers().stream()
.mapToInt(Customer::age)
.average().orElse(0d);}
}
12

13. Loose coupling, dependency injection instead of objects creation
● Example – injected collaborator, test
@Test
public void shouldCalculateAverageCorrectly(){
when(repository.customers()).thenReturn(
asList(
Customer.withAge(20),
Customer.withAge(30))
);
final CustomerLogic underTest = new CustomerLogic(repository);
assertThat(
underTest.averageCustomersAge(),
is(25d));
}
13

14. Loose coupling
➢
Replace creation of new objects with
dependency injection
➢
Inject all collaborators in the constructor
➢
If forced by the api, create fake constructors
visible from the unit tests
➢
Handle the bloated constructors nicely
14

15. Loose coupling, inject collaborators in constructor
● The dependencies are visible in the class API
● It is really easy to write unit tests. When you
instantiate the component under test, you just call
the constructor, passing mocks, or test doubles as
arguments
● You can design immutable classes
15

16. Loose coupling, dependency injection instead of objects creation
● It indicates possible design flaws: is your class
still cohesive and follows the single responsibility
principle, if it has way too many collaborators?
● Avoid the field injection, even if your dependency
injection system allows it
16

17. Loose coupling
➢
Replace creation of new objects with
dependency injection
➢
Inject all collaborators in the constructor
➢
If forced by the api, create fake constructors
visible from the unit tests
➢
Handle the bloated constructors nicely
17

18. Loose coupling, fake test constructors
● If the API forces a constructor signature that does
not allow the injection of the collaborators, do not
unit test this main constructor
● Create a package-private constructor, that
accepts all collaborators as parameters
● Unit test this package-private constructor
18

19. Loose coupling, fake test constructors
● Example, difficult to test version
// The signature is forced by the API, cannot be changed
public MessageCenter(final String id){
super(id);
this.notificationService = new NotificationService();
this.mailService = new MailService();
}
● This constructor cannot be unit tested in a
simple, clean way
19

20. Loose coupling, fake test constructors
● Example, the easy to test version
// The signature forced by the API, cannot be changed
public MessageCenter(final String id){
this (id, new NotificationService(), new MailService());
}
// You can easy test this constructor
MessageCenter(final String id,
final NotificationService notificationService,
final MailService mailService) {...}
20

21. Loose coupling
➢
Replace creation of new objects with
dependency injection
➢
Inject all collaborators in the constructor
➢
If forced by the api, create fake constructors
visible from the unit tests
➢
Handle the bloated constructors nicely
21

22. Loose coupling, handle bloated constructor
● Injecting all the dependencies in the constructor
can lead to a long parameter list
● A long parameter list can signalize lack of
cohesion and therefore you should consider
refactoring the class in order to split the concerns
22

23. Loose coupling, handle bloated constructor
● If refactoring is not required, search for
parameters that belong together:
– Group the components into a new class. Use a
single instance of the class as constructor
argument
– Use composition. Inject one object into another
and use a single instance of the main class as
constructor argument
23

24. What makes your code easy to test
Loose
coupling No static
calls
24
Logic free
constructors
Compact
data
creation
Clear intent

25. Logic free constructors are easy to test
Avoid smart, or hard working constructors

26. Design logic free constructors
● The code in the constructor is run by each test. A
“hard working” constructor makes your tests slow
● Avoid any object creation in the constructor, like
connections, entity managers, or providers
● Any “new” call in constructor could trigger a
pyramid of calls, that will make your tests slow
and brittle
26

27. Design logic free constructors
● The constructors should ideally just initialize
instance variables with constructor arguments
values
● The usage of “init()” blocks, post construct
blocks, or static code initializers is cheating and
we know it
27

28. What makes your code easy to test
Loose
coupling No static
calls
28
Logic free
constructors
Compact
data
creation
Clear intent

29. 29
The instance method calls are easy to fake
Use them as long as possible, avoid static calls

30. Static calls
➢
Collaborators are not visible in your API
➢
Collaborators behavior can change without
notice
➢
Static calls can force you to register transitive
dependencies
➢
Singletons are dependencies
30

31. No static calls, collaborators not declared in API
● The collaborators that receive the static call are
not declared transparently, in the public API
● The static calls are like secret communication
channels to unknown entities
● Replacing the static calls with instance calls on
injected collaborators make the API clear
31

32. Static calls
➢
Collaborators are not visible in your API
➢
Collaborators behavior can change without
notice
➢
Static calls can force you to register transitive
dependencies
➢
Singletons are dependencies
32

33. No static calls, collaborator's behavior changes
● Since not all the mocking frameworks support
static calls, you might end up running real static
calls and faking some second level dependencies
● If the receiver of a static call delegates to another
collaborator, the mock rules will not be triggered
● The tests can fail with no reason (false positives)
and are no longer a refactoring safety net
33

34. Static calls
➢
Collaborators are not visible in your API
➢
Collaborators behavior can change without
notice
➢
Static calls can force you to register transitive
dependencies
➢
Singletons are dependencies
34

35. No static calls, transitive dependencies
● If the tests run real static calls, you might be
forced to register in the test also the static
collaborators dependencies
● Example: if the collaborator uses a globally
defined WebSession object, your test should also
register it in the ThreadLocal
● You might be forced to run the test in a suite
35

36. Static calls
➢
Collaborators are not visible in your API
➢
Collaborators behavior can change without
notice
➢
Static calls can force you to register transitive
dependencies
➢
Singletons are dependencies
36

37. No static calls, singletons
● Singletons are provided over a static factory
method call, that can not be mocked. You need to
mock the singleton dependencies
● Since the singleton behavior can change without
notice, you should treat it as a dependency
● Prefer injecting beans with singleton scope. Their
method calls can also be cached
37

38. What makes your code easy to test
Loose
coupling No static
calls
38
Logic free
constructors
Compact
data
creation
Clear intent

39. 39
The tests need to create data
Builders are better than setters

40. Compact data creation
● It is really difficult to create complex test data, if
the domain classes expose only setters and
allArgsConstructors
● If you control the domain classes, make sure you
design them small and cohesive
● Consider providing builders and / or “with”-ers as
alternative to setters
40

41. Compact data creation
● Setters mean mutable objects. Use them only if
you really need data objects
● The creation of Java beans in the test leads to
long set up methods, that are hard to follow and
boring to read
● AllArgsConstructor calls force the tests to provide
values for all the bean fields, even if irrelevant
41

42. Compact data creation
● The builders can create immutable objects
● The builders let you initialize just the relevant
fields
● The builders can also initialize behind the scene
fields with default values, avoiding duplicated
code in each test method
42

43. Compact data creation
● The builders and “with”-ers calls can be chained,
increasing the code readability
● Example - “with”-ers
Customer regular = customer()
.withName(“name”)
.withId(123L)
.withSubscription(456L);
43

44. Compact data creation
● Example – builder:
Customer company = Customer.companyBuilder()
.name(“company A”)
.id(1234567L)
.taxAddress(someAddress())
.mainOfficeAddress(someOtherAddress())
.build();
Customer private = Customer.privateBuilder()
.name(“Joe”)
.birthday(“1970-01-01”)
.homeAddress(“some address”)
.postalAddress(“some other address”)
.build();
44

45. What makes your code easy to test
Loose
coupling No static
calls
45
Logic free
constructors
Compact
data
creation
Clear intent

46. 46
Write clear code, not smart one
The tests and the readers of your code will be thankful

47. Clear intent, no magic
● There is way more time invested in maintenance,
than in the original code development
● Other developers will most likely extend your
code
● The tests should document the code. The good
code is simple and its intent is clear. Avoid smart
tricks and hidden functionality
47

48. Clear intent, no magic
● Smell: getter with extra functionality
class UserMonitor {
private User currentUser;
User currentUser(){
if (this.currentUser == null) {
this.currentUser = loadUser();
validationService.check(currentUser);
outboundService.scan(currentUser);
}
}
}
● A whole jungle is hidden behind the getter call
48

49. Clear intent, no magic
● Smell: return default values if not initialized
class User {
private final List<Subscription> subscriptions;
List<Subscription> subscriptions(){
return subscriptions == null ? trial() : subscriptions;}}
● The test code would check if there is a trial
subscription for every user, that has no
subscriptions
49

50. Clear intent, no magic
● Smell: add data to match client requirements
class ServiceLayerMapper {
// The user interface algorithm needs an extra empty product!
public List<Product> mapBuyedItems(){
return asList(
emptyProduct(),
mappedItems(purchasedItems())
);
}
● The test code will check if there is always an item
in the basket, if the user does not buy anything
50

51. CREDITS
● Growing Object-oriented software, guided by tests (Steve Freeman, Nat
Pryce)
● Stephen Colebourne, Code generating beans in java:
https://www.slideshare.net/scolebourne/code-generating-beans-in-java
● Misko Hevery, testability explorer blog:
http://misko.hevery.com/code-reviewers-guide/
http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
● Effective Java, Joshua Bloch
● Elegant objects, Yegor Bugayenko
51

52. CREDITS
● Presentation template by SlidesCarnival
● Photographs by Unsplash
● Diverse device hand photos by Facebook Design Resources
● www.freepik.com photos:
– Designed by mrsiraphol / Freepik
– Designed by ijeab / Freepik
– Designed by Onlyyouqj / Freepik
– Designed by ijeab / Freepik
– Designed by Dashu83 / Freepik
52

53. Any questions?
You can find me at:
marian.wamsiedel@gmail.com
53THANKS!