1. The document discusses designing code for testability. It emphasizes dependency injection and mocking to easily instantiate classes and invoke methods during testing without dependencies. 2. It also discusses avoiding private and static methods when possible since they cannot be overridden or replaced, making the code harder to test. Following good design practices like the SOLID principles leads to more testable code. 3. The document provides examples of refactoring code to make it more testable through dependency injection and interfaces. This allows dependencies to be mocked or stubbed during testing and makes the code easier to extend.

1. Design Code That's Easy to Test
Design for Testability

2. Better safe than sorry
It is better to do something carefully in advance than to su er later

3. Insu icient testing
No documentation
This never ends well
Eeasy to ignore or shortchange,
especially on projects with a
tight budget
Poor code quality
Smells really bad!
Technical debt
The implied cost of additional rework caused by choosing an easy
solution now instead of a better approach that would take longer

4. "Design the so ware to make it more easy to test"
Design for Testability

5. " The degree to which a system facilitates
the establishment of test criteria and the
performance of tests to determine whether
those criteria have been met "
IEEE, 1990 " Having reliable and convenient
interfaces to drive the execution
and verification of tests "
B. Pettichord
" Characteristic of a so ware
which allows it to be easily
and e iciently tested "
(Bach 1999, Gelperin 1999)
Testability

6. Which code is easier to test?
public class MyCalendar {
public boolean isWeekDay(){
int day = Calendar.getInstance()
.get(Calendar.DAY_OF_WEEK);
return day Calendar.SATURDAY
day Calendar.SUNDAY;
}
}
public class MyCalendar {
public boolean isWeekDay(Calendar calendar){
int day = calendar.get(Calendar.DAY_OF_WEEK);
return day Calendar.SATURDAY
day Calendar.SUNDAY;
}
}

7. Types of Testing
Unit Testing Integration Testing System Testing Acceptance Testing
and many others more
01 02 03 04

8. Map the issue to the
solution
Instantiating a class
and invoke methods
Isolation from dependencies Verify interactions
When writing unit tests we usually face some issues, such as

9. Dependency injection
A process used in unit testing when the unit being tested has external
dependencies. It aims to isolate and focus on the code being tested and not on
the behavior or state of the external dependencies
Mocking
A design pattern in which an object or function receives other objects or
functions that it depends on. It aims to separate the concerns of constructing
objects and using them, leading to a loosely coupled program

10. What would you do to easily instantiate classes
and invoke methods during testing?
Dependency injection Mocking Write clean code and avoid
private, final, and static
Question 1/3
Map the issue to a possible solution

11. Question 2/3
How would you prevent a class from
instantiating its own dependencies?
Dependency injection Mocking
Map the issue to a possible solution
Write clean code and avoid
private, final, and static

12. Question 3/3
How would you simulate the behavior of the real
object and eventually verify its interactions?
Dependency injection Mocking
Map the issue to a possible solution
Write clean code and avoid
private, final, and static

13. Congratulations!
Start over?
🎉

14. Be pragmatic and precise while doing it
Write Clean and
SOLID Code
1

15. Clean code
A code than any developer can read and change easily
Testable
Simple
Establish a baseline behaviour
and makes it easier to change
Increasing complexity makes the
code error-prone and di icult to
maintain
Focused
A piece of code should solve
only a specific problem

16. Beware Code Smells
Symptoms of poor design or implementation choices. Classes that experience those symptoms
are more change- and fault-prone than others
Bloaters
Hard to work with due to their
incresed proportions
Couplers
Contribute to excessive
coupling between classes
Long Method Large Class
Long Parameter List
Feature Envy Message Chain

17. Refactoring
It's always worth investigating if we can refactor our code to
make it more testable

18. Test early and o en
Instil a culture of
testing
2

19. " All so ware will be tested - either by you and your
team or by the eventual users - so you might as well
plan on testing it thoroughly "
Andrew Hunt, The Pragmatic Programmer

20. Test-driven development (TDD)
A so ware development approach in which test cases are developed to specify
and validate what the code will do

21. The TDD cycle
public class MyCalendar {
public boolean isWeekDay(Calendar calendar){
int day = calendar.get(Calendar.DAY_OF_WEEK);
return day Calendar.MONDAY day Calendar.TUESDAY
day Calendar.WEDNESDAY day Calendar.THURSDAY
day Calendar.FRIDAY;
}
}
void testIsWeekDay(){
var calendar = Calendar.getInstance()
.set(2022, 8, 2);
assert new MyCalendar().isWeekDay(calendar);
}
}
public class MyCalendar {
public boolean isWeekDay(Calendar calendar){
return false;
}
}
public class MyCalendar {
public boolean isWeekDay(Calendar calendar){
int day = calendar.get(Calendar.DAY_OF_WEEK);
return day Calendar.SATURDAY day Calendar.SUNDAY;
}
}

22. TDD forces you to think about design for testability upfront
TDD forces you to think about design for testability upfront
Not a silver bullet: still focuses on development than testing
Not a silver bullet: still focuses on development than testing
No better way to fix errors than preventing them
No better way to fix errors than preventing them
vs
Test early and o en
Instil a culture of
testing
2

23. Inject
Dependencies
3Yet, depend on abstractions, not on concretions

24. public class MyApp {
GithubService githubService = new GithubService();
public int countRepos(String token){
List<String> repos = new ArrayList ();
try{
githubService.authenticate(token);
repos = githubService.collectRepos();
}catch(TimeoutExceeded e){
;
}
return repos.size();
}
}
public class GithubService {
void authenticate(String token) throws TimeoutExceeded {
if(new Random().nextInt(5) 0)
throw new TimeoutExceeded();
Do something, e.g. set APIs quota
}
public List<String> collectRepos(){
return List.of("sdp/myrepo");
}
}
@Test
void testCollectRepos(){
MyApp app = MyApp();
assert app.countRepos("mytoken") 1;
}
@Test
void testCollectReposTimeoutExceeded(){
MyApp app = MyApp();
assert app.countRepos("mytoken") 0;
}

25. MyApp GithubService
Hard-coded dependency
If we want to switch to a different service in the future, e.g., a GitlabService or a
BitbucketService, it will require code changes in MyApp. This makes our
application hard to extend
Testing the application will be very difficult since our application is directly
instantiating the service. There is no way we can mock that object in our tests

26. Client
Service
ServiceInterface
Injector
4 Roles
depends on
implements
uses
injects

27. public class
public class MyApp {
MyApp {
GithubService githubService
GithubService githubService;
;
public
public MyApp(
MyApp(GithubService service
GithubService service){
){
githubService = service;
githubService = service;
}
}
public
public List<String>
List<String> collectRepos
collectRepos(String token){
(String token){
List<String> repos =
List<String> repos = new
new ArrayList ();
ArrayList ();
try
try{
{
githubService.authenticate(token);
githubService.authenticate(token);
repos = githubService.collectRepos()
repos = githubService.collectRepos()
}
}catch
catch(TimeoutExceeded e){
(TimeoutExceeded e){
;
;
}
}
return
return repos.size();
repos.size();
}
}
}
}
public class GithubService {
}
class LazyGithubService extends GithubService {
@Override
void authenticate(String token){
throw new TimeoutExceeded("You know I'm lazy :)");
}
}
@Test
void testCollectReposTimeoutExceeded(){
MyApp app = MyApp(new LazyGithubService());
var repos = app.countRepos("mytoken");
assert repos 0;
}

28. MyApp
GithubService
implementation
RepoHostingService
interface
GitlabService
implementation
public class GithubService implements RepoHostingService
{
@Override
void authenticate(String token){ };
}
public class GitlabService implements RepoHostingService
{
@Override
void authenticate(String token){ };
}
public class
public class MyApp {
MyApp {
RepoHostingService
RepoHostingService service
service;
;
public
public MyApp(
MyApp(RepoHostingService
RepoHostingService service){
service){
this.
this.service = service;
service = service;
}
}
}
}
public interface
public interface RepoHostingService {
RepoHostingService {
void
void authenticate
authenticate(String token);
(String token);
}
}

29. @Test
void testCollectGithubRepos(){
RepoHostingService service = new GithubService();
MyApp app = MyApp(service);
var repos = app.countRepos("mygithubtoken");
assert repos 1;
}
@Test
void testCollectGitlabRepos(){
RepoHostingService service = new GitlabService();
MyApp app = MyApp(service);
var repos = app.countRepos("mygitlabtoken");
assert repos 1;
}
@Test
void testCollectReposTimeoutExceededMock(){
String token = "mytoken";
RepoHostingService service = mock(GithubService.class);
doThrow(new TimeoutExceeded()).when(service)
.authenticate(token);
MyApp app = MyApp(service);
var repos = app.countRepos(token);
assert repos 0;
}

30. MyApp RepoHostingService
Injector GithubService
public class ServiceInjector {
public MyApp getConsumer(String hostingService) {
var service = switch(hostingService) {
case "github" new GithubService();
case "gitlab" new GitlabService();
}
return new MyApp(service);
}
}

31. Eases testing by enabling mocking and stubbing
Eases testing by enabling mocking and stubbing
Eases extension by depending on abstractions
Eases extension by depending on abstractions
vs
With frameworks like Spring, boilerplate code is reduced
With frameworks like Spring, boilerplate code is reduced
If overused can lead to management issues
If overused can lead to management issues
Many compile-time errors are pushed to run-time
Many compile-time errors are pushed to run-time
Tricky to understand at the beginning
Tricky to understand at the beginning
Yet, depend on abstractions, not on concretions
Inject
dependencies
3

32. Avoid private &
static
4When possible

33. Protected methods are accessible by the unit test if it is
located in the same package as the unit to test, though
still under a di erent root directory
Turning private
into protected

34. Avoid static methods
Static methods can't be overridden and replaced and
therefore are harder to fake; they require a combination of
frameworks to be tested

35. Write clean and SOLID code
Following good design
practices leads to a more
testable system
Avoid private & static
Private and static methods can't
be overridden and replaced and
therefore are harder to fake
Inject dependencies
This will allow fakes to be
inserted instead of real logic,
making isolation easy
Instil a culture of testing
Early testing guides
(re)design
Design for Testability Recommendations
Avoid code smells
And investigate refactoring
before taking design
decisions

36. No one-size-fits-all
Excercise judgement when designing and testing by considering the
interactions between them, and pros and cons of each decision

37. What are the recommedation
most import to you...
Create your own standings by sorting the boxes
Avoid code smells
Instil a culture of testing
Inject dependencies
Write clean code
1)
2)
3)
4)
5) Avoid statics & privates
and your questions?

38. Oops not correct
Try again!