Is this how you hate unit testing?
-
Upload
steven-mak -
Category
Technology
-
view
1.152 -
download
1
description
Transcript of Is this how you hate unit testing?
www.odd-e.com
I hate unit testing!!!
Friday, 9 December, 11
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
本故事純屬虛構如有雷同實屬巧合
3
Friday, 9 December, 11
I HATE UNIT TESTING!
4
•Doesn’t catch many bugs•Still need to do integration tests•Waste time
Friday, 9 December, 11
Need to test at integration level anyway?
5
Is this what you mean by integration testing?
Friday, 9 December, 11
How many tests do you need to cover through system level tests?
6
10states
10states
10states
5 interactions 5 interactions
5 interactions
Adapted from: http://www.renaissancesoftware.net/files/sglon/LondonScrumGathering-v1r0.key.pdf
Tests
• It would take 1000 (or more) tests to this simple system!• System Level Tests just cannot be thorough
Friday, 9 December, 11
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
Test Automation Pyramid
8
You are going to need some integration tests, but not in the way you do like unit tests.
Friday, 9 December, 11
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.
9
http://b-speaking.blogspot.com/search/label/integration%20tests
Friday, 9 December, 11
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
Example:
11
@Testpublic void with_arguments(){! MyCollaborator c = mock(MyCollaborator.class);! when(c.compareTo("Test")).thenReturn(1);! assertEquals(1,a.doSomethingElse("Test"));}
We are assuming that compareTo() would return 1 if we pass in “Test”
@Testpublic void compareToShouldReturnOne(){! ! MyCollaborator c = new MyCollaborator();! ! assertEquals(1,c.compareTo("Test"));}
We write a test for the real MyCollaborator.compareTo()
Contract tests are usually slow but tend to be stable. Often running just once a day is plenty
Friday, 9 December, 11
Refactoring?
12
Code smells!
Code stinks!
It’s no fun writing unit test if you don’t spend time refactoring
Friday, 9 December, 11
Why? How?
13
amount of bad
code
panic
amount of code
smells
time spend on
bug fixing
motivation
developers
quick hacks
opportunity for
# of bugs
indicates
O
refactoring
O
Friday, 9 December, 11
Refactoring visualized
14
Original program:
Making changes:
More changes:
Without refactoring:
Friday, 9 December, 11
Refactoring visualized
14
Original program:
Making changes:
More changes:
Without refactoring:
Friday, 9 December, 11
Refactoring visualized
14
Original program:
Making changes:
More changes:
Without refactoring:
Cost of change increases rapidly!
Friday, 9 December, 11
Refactoring visualized
14
Original program:
Making changes:
More changes:
Without refactoring:
Cost of change increases rapidly!
With refactoring:
Friday, 9 December, 11
Refactoring visualized
14
Original program:
Making changes:
More changes:
Without refactoring:
Cost of change increases rapidly!
With refactoring:
Small change
Friday, 9 December, 11
Refactoring visualized
14
Original program:
Making changes:
More changes:
Without refactoring:
Cost of change increases rapidly!
With refactoring:
Small change
Friday, 9 December, 11
Refactoring visualized
14
Original program:
Making changes:
More changes:
Without refactoring:
Cost of change increases rapidly!
With refactoring:
Small change
Refactor
Friday, 9 December, 11
Refactoring visualized
14
Original program:
Making changes:
More changes:
Without refactoring:
Cost of change increases rapidly!
With refactoring:
Small change
Refactor
Friday, 9 December, 11
Refactoring visualized
14
Original program:
Making changes:
More changes:
Without refactoring:
Cost of change increases rapidly!
With refactoring:
Small change
Refactor
Etc
Cost of change not increases
Friday, 9 December, 11
Refactoring based on unit testing
15
Friday, 9 December, 11
What to refactor?
16
Friday, 9 December, 11
Beware of blocking
17
• Individual Code Ownership?• Branching for long time?• Deadline pressure?
- Refactoring makes your code base easier to work on
Friday, 9 December, 11
Time consuming?
18
Too busy fire fighting, but no time to write tests?
Friday, 9 December, 11
Speculate Code Test Debug
Sustainability
19
Traditional development
Time vs
Friday, 9 December, 11
Speculate Code Test Debug
Sustainability
19
Traditional development
Time developers do not notice nor plan for
Time vs
Friday, 9 December, 11
Speculate Code Test Debug
Sustainability
19
Traditional development
Time developers do not notice nor plan for
Time vs
Test-driven development
Speculate Test and Code Debug
Friday, 9 December, 11
Speculate Code Test Debug
Sustainability
19
Traditional development
Time vs
Test-driven development
Speculate Test and Code Debug
Feels slower
Friday, 9 December, 11
20
We are tired of delivering craps
Do you have confidence with your work before you deliver it?
Friday, 9 December, 11
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
TDD Cycle
22
Test
Implement
Design
• Short• Rhythmic• Incremental • Design-focused• Disciplined
Friday, 9 December, 11
Oh, Our code was there already
23
1. Identify change point2. Find test points3. Break dependencies4. Write tests5. Make changes and refactor
It is always harder to write unit tests after we wrote the code
Friday, 9 December, 11
Our code is too simple, so we don’t need unit testing
24
Our code is too complicated, so writing unit tests is too difficult
We don’t have problems at unit level
Friday, 9 December, 11
Tests you write after the fact are Defense or Justification
25
• 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.
Friday, 9 December, 11
Unit test is not just about testing
26
Look at the design through unit tests
Friday, 9 December, 11
Modularity == Testability
27
Focus on tests first ensures modularity and other good design principles
Friday, 9 December, 11
28
Design from the perspective of userather than implementation
Friday, 9 December, 11
• 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
It is always harder to write unit tests after we wrote the code
Friday, 9 December, 11
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
• 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
TDD, The Professional Option
Friday, 9 December, 11
Resources
32
Friday, 9 December, 11
Agile Tour ShenZhen• Tencent Building, Shenzhen (騰訊大廈)
- 20 Nov 2011- Tencent Building, Kejizhongyi Avenue, Hi-techPark,Nanshan
District,Shenzhen.- 深圳市南山区科技园科技中一路腾讯大厦,深南大道北侧
• http://www.agiletour.cn• Contact: [email protected]
33
Friday, 9 December, 11
I want to organise a group in Hong Kong!
34
http://tinyurl.com/HKALSDN
Friday, 9 December, 11
Further readings
35
• Integration Tests are a Scam:- http://www.jbrains.ca/series/integrated-tests-are-a-scam
• Integration Contract Tests:- http://martinfowler.com/bliki/IntegrationContractTest.html
• Opportunistic Refactoring:- http://martinfowler.com/bliki/OpportunisticRefactoring.html
• Demand Technical Excellence:- http://www.renaissancesoftware.net/files/sglon/
LondonScrumGathering-v1r0.key.pdf• Clean Coder, by Robert Martin
Friday, 9 December, 11
Books - Technical Practices
36
Friday, 9 December, 11