1. www.odd-e.com
I hate unit testing!!!
Friday, 9 December, 11
2. Who am I?
• Name: Steven Mak
• Agile Coach at Odd-e
• Lives in Hong Kong
• Agile, TDD Coaching
• I love coding - Java, C/C++,
PHP, Perl, and some weird
ones
• I speak English, Cantonese,
and Mandarin
2
Friday, 9 December, 11
4. I HATE UNIT TESTING!
• Doesn’t catch many bugs
• Still need to do integration tests
• Waste time
4
Friday, 9 December, 11
5. Need to test at integration
level anyway?
Is this what you mean by integration testing?
5
Friday, 9 December, 11
6. How many tests do you need to cover
through system level tests?
10
states
Tests 5 interactions
5 interactions
10 5 interactions
10
states states
• It would take 1000 (or more) tests to this simple system!
• System Level Tests just cannot be thorough
6
Adapted from: http://www.renaissancesoftware.net/files/sglon/LondonScrumGathering-v1r0.key.pdf
Friday, 9 December, 11
7. The down side
• Tons of them to write
• False sense of security
• Integration tests are slow
• Hard to diagnose
• Brittle
- one change would trigger many test failures
7
Friday, 9 December, 11
8. Test Automation Pyramid
You are going to need some integration tests,
but not in the way you do like unit tests. 8
Friday, 9 December, 11
9. Write good focused unit tests
• Don’t test the platform.
• When writing a single object to test with other
collaborating objects, use interfaces for those
other points. Interfaces are not the actual
collaborating object.
• Leverage the interfaces so you don’t need to
actually test the other objects.
• Test the single object to speak to itself, i.e.
State Tests
• Create your focused Collaboration and
Contract Tests.
http://b-speaking.blogspot.com/search/label/integration%20tests
9
Friday, 9 December, 11
10. Collaboration and Contract Tests
• Collaboration tests:
- Do I ask the collaborators the right questions?
- Can I handle the collaborators’ responses?
• Contract tests:
- Can the interface accept the question being asked of it?
- Can the interface supply the responses expected?
10
Friday, 9 December, 11
11. Example:
We are assuming that
@Test compareTo() would return 1
public void with_arguments(){ if we pass in “Test”
! MyCollaborator c = mock(MyCollaborator.class);
! when(c.compareTo("Test")).thenReturn(1);
! assertEquals(1,a.doSomethingElse("Test"));
}
@Test
public void compareToShouldReturnOne(){ We write a test for the real
! ! MyCollaborator c = new MyCollaborator(); MyCollaborator.compareTo()
! ! assertEquals(1,c.compareTo("Test"));
}
Contract tests are usually slow but tend to be
stable. Often running just once a day is plenty 11
Friday, 9 December, 11
12. Refactoring?
Code smells!
Code stinks!
It’s no fun writing unit test if you don’t spend time refactoring
12
Friday, 9 December, 11
13. Why? How?
opportunity for
refactoring
amount of code
smells
O indicates motivation
developers
O
amount of bad
code
quick hacks
# of bugs panic
time spend on
bug fixing
13
Friday, 9 December, 11
14. Refactoring visualized
Without refactoring:
Original program:
Making changes:
More changes:
14
Friday, 9 December, 11
15. Refactoring visualized
Without refactoring:
Original program:
Making changes:
More changes:
14
Friday, 9 December, 11
16. Refactoring visualized
Without refactoring:
Original program:
Making changes:
More changes:
Cost of change
increases rapidly! 14
Friday, 9 December, 11
17. Refactoring visualized
Without refactoring: With refactoring:
Original program:
Making changes:
More changes:
Cost of change
increases rapidly! 14
Friday, 9 December, 11
18. Refactoring visualized
Without refactoring: With refactoring:
Original program:
Small change
Making changes:
More changes:
Cost of change
increases rapidly! 14
Friday, 9 December, 11
19. Refactoring visualized
Without refactoring: With refactoring:
Original program:
Small change
Making changes:
More changes:
Cost of change
increases rapidly! 14
Friday, 9 December, 11
20. Refactoring visualized
Without refactoring: With refactoring:
Original program:
Small change
Refactor
Making changes:
More changes:
Cost of change
increases rapidly! 14
Friday, 9 December, 11
21. Refactoring visualized
Without refactoring: With refactoring:
Original program:
Small change
Refactor
Making changes:
More changes:
Cost of change
increases rapidly! 14
Friday, 9 December, 11
22. Refactoring visualized
Without refactoring: With refactoring:
Original program:
Small change
Refactor
Making changes:
Etc
More changes:
Cost of change Cost of change
increases rapidly! not increases 14
Friday, 9 December, 11
25. Beware of blocking
• Individual Code Ownership?
• Branching for long time?
• Deadline pressure?
- Refactoring makes your code base easier to work on
17
Friday, 9 December, 11
26. Time consuming?
Too busy fire fighting, but no time to write tests?
18
Friday, 9 December, 11
27. Sustainability
Traditional Speculate Code Test Debug
development
Time vs
19
Friday, 9 December, 11
28. Time developers
do not notice
Sustainability nor plan for
Traditional Speculate Code Test Debug
development
Time vs
19
Friday, 9 December, 11
29. Time developers
do not notice
Sustainability nor plan for
Traditional Speculate Code Test Debug
development
Time vs
Test-driven Spec
Test and Code Debug
development ulate
19
Friday, 9 December, 11
30. Sustainability
Traditional Speculate Code Test Debug
development
Time vs
Feels
slower
Test-driven Spec
Test and Code Debug
development ulate
19
Friday, 9 December, 11
31. We are tired of
delivering craps
Do you have confidence with your work
before you deliver it? 20
Friday, 9 December, 11
32. Edsger Dijkstra
“Those who want really reliable
software will discover that they must
find means of avoiding the majority
of bugs to start with, and as a result,
the programming process will
become cheaper. If you want more
effective programmers, you will
discover that they should not waste
their time debugging, they should
not introduce the bugs to start with.”
21
Friday, 9 December, 11
34. Oh, Our code was there already
1. Identify change point
2. Find test points
3. Break dependencies
4. Write tests
5. Make changes and refactor
It is always harder to write unit tests
after we wrote the code 23
Friday, 9 December, 11
35. Our code is too simple,
so we don’t need unit testing
Our code is too complicated,
so writing unit tests is too difficult
We don’t have problems at unit level
24
Friday, 9 December, 11
36. Tests you write after the fact are
Defense or Justification
• Test later = Test never
• After-the-fact tests are written by someone
who is already vested in the code and
already knows how the problem was solved
• There’s just no way those tests can be
anywhere near as incisive as tests written
first
• If you write the unit test after the fact, you
are not going to catch many bugs.
25
Friday, 9 December, 11
37. Unit test is not just about testing
Look at the design through unit tests
26
Friday, 9 December, 11
38. Modularity == Testability
Focus on tests first ensures modularity
and other good design principles 27
Friday, 9 December, 11
39. Design from the perspective of use
rather than implementation
28
Friday, 9 December, 11
40. It is always harder to write unit tests
after we wrote the code
• Debug-later-programming don’t consider testability in the first place
• TDD guarantees testability, while you still need to know good design
principles
• Unit tests give you a safety net to try different design
29
Friday, 9 December, 11
41. When you find it hard to
write unit tests...
• Instantiating class instance that is hard to setup?
- What about using Factories?
- Have you think about Dependency Injection?
• Long methods?
- Does it have more than one responsibilities?
• Bare classes?
- Why not provide abstract base classes to support better mocking?
- Why clients need to know everything from this base class?
• Interface Segregation Principle
30
Friday, 9 December, 11
42. TDD, The Professional Option
• Confidence and trust in the code
- Treading the happy path
- “If it doesn’t have to work, I can get it done a lot faster!”
- “Cost of bug fixing is lower if it is found earlier”
• Encourages good design
- Clean it up later
- Experimenting different design
• Integration Testing
- Making assumptions explicit
31
Friday, 9 December, 11
