Beyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Driving Quality with TDD
1. Driving Quality with TDD
Steven Mak 麥天志
steven@odd-e.com
www.odd-e.com
Thursday, 6 May 2010
2. About me
• Steven Mak 麥天志
• Agile Coach at Odd-e
• Lives in Hong Kong
• I do speak Mandarin!
• Agile, TDD Coaching
• Love to code
Thursday, 6 May 2010
3. Agenda
• Why you care?
• What you can do?
• How to implement?
Thursday, 6 May 2010
5. 5
OK, I don’t want Legacy Code
• Don’t write legacy code
• Improve development skills
• Clean up your neighbourhood
• Write both high-level and unit tests
• Raise awareness of the negative impact
Thursday, 6 May 2010
6. 6
Boy Scout Rule
• If we all checked-in our code a little cleaner than
when we checked it out, the code simply could
not rot
Valuecode/designquality
Time
effortneededforchange
Time
Thursday, 6 May 2010
7. 7
What is “testing” anyway?
• What do you need to do before you can ship
your product?
• Simple testing classifications!
– Customer-facing tests, whether the
requirements are fulfilled
– Developer tests, system does what the
developer intended
Thursday, 6 May 2010
10. 10
We need Unit Tests
• New Functionality
• Fix problems
• Improve design
• Optimise resources
• “Edit and Pray” or “Cover and Modify”?
Thursday, 6 May 2010
11. 11
Good Unit Tests
• Fast
• Localise problems
• Readable
• One assertion per tests
• Don’t forget higher level/Customer-facing tests
Thursday, 6 May 2010
12. 12
What is not unit tests
• It talks to database
• It communicates across a network
• It touches the file system
• It requires special things to be done in your
environment (e.g. editing configuration files)
Thursday, 6 May 2010
13. 13
Test Driven Development
• 1 Rule
– Only ever write code to fix a failing test
• 3 Steps
– Write a test (which is “red”)
– Code (to make test pass “green”)
– Refactor (test still pass “green”)
Thursday, 6 May 2010
14. 14
What is Refactoring?
• A series of small steps, each of which
changes the program’s internal structure
without changing its external behaviour
Thursday, 6 May 2010
15. 15
Refactoring
• Explain by analogy
– Tidy up at home
– Cleaning hands after surgery
• Refactoring Workbook – Bill Wake
• Aware of code smells
• Relentlessly refactoring
• Any tools available?
• Don’t forget refactoring tests
Thursday, 6 May 2010
16. 16
• Duplicated Code
• Long Method
• Large Struct/Class
• Long parameter list
• Switch statements
• Comments
Code Smells
Thursday, 6 May 2010
17. 17
• No, you still want to do modelling...
• Design workshop
• Model to have a conversations
• Joint design workshops for broader design
issues
• Technical leaders teach at workshops
I heard that we don’t need
modelling with TDD...?
Thursday, 6 May 2010
18. 18
CI is a developer practice
• CI is not merely about a tool
• Encourage splitting changes into small
increments
• TDD fits well with CI practice
• Shaming people has a negative effect
Thursday, 6 May 2010
20. Can I start on the next
Monday?
20
Thursday, 6 May 2010
21. 21
Convincing your boss
(or yourself)
• Cost of bug fixing is lower if it is found earlier
• In 2008, Case study of TDD at IBM and Microsoft shows
that TDDers enjoy a defect density reduction ranging
from 30% to 90% and a productivity cost of between
15% and 35%
http://research.microsoft.com/en-us/projects/esm/
nagappan_tdd.pdf
• Kent Beck: “If it doesn’t have to work, I can get it done a
lot faster!”
Thursday, 6 May 2010
22. 22
So you want to start?
• Get the team members started writing a few
automated tests before trying to drive their code
with tests
• Spend time working with the team to understand
the real state of the code, the level of
experience of the team members, and how
interested each of them is in making changes to
the way they work
• The team needed to work together to establish a
test strategy and to agree on how they would
organise their tests into a shared suite that
anyone in the team could run
Thursday, 6 May 2010
23. 23
Buy-in from the Team
• It takes time for the team to learn, allow time in
their planning for learning
• Any compelling reasons before they will
commit to making on the extra work of writing
automated tests?
• Most team begins with:
– Write tests for new code and any changes to
existing code
• Discuss with the team and see if they are
committed to do this
• Target of writing a few tests every day
Thursday, 6 May 2010
25. 25
A lots of coaching!
• No structure in place to decide when and with
teams to work?
• Internal coaches were asked to do normal
development?
• Not listening to internal coaches?
• Coaching skills not appreciated and further
developed?
• Both internal and external coaching!
Thursday, 6 May 2010
26. 26
Sustaining TDD
• One-line changes accumulate and turn
into legacy code
• Make test coverage more visible
• Look for new areas of their architecture
that they don’t have tests for
– UI?
– Logs?
– Print outs?
Thursday, 6 May 2010
27. 27
Test smells
• Pay attention to the time it takes to build
the application and run the tests
• Watch out for poorly designed tests and
its dependencies
• Isolate long running tests into a separate
test suite that is run in the background
Thursday, 6 May 2010
28. 28
Maintain Test-First Discipline
• Working in pairs to discuss design
• Write automated tests and achieve a
similar level of test coverage as a trial
period
Thursday, 6 May 2010
29. 29
Pair Programming helps
reinforcing test first discipline
• Ping-Pong programming
• Videos of how others do
• Think it aloud
• How Pair Programming Works:
– http://www.computer.org/cms/Computer.org/ComputingNow/homepage/
2010/0110/W_SW_PairProgramming.pdf
Thursday, 6 May 2010
30. 30
No Test tools Available?
• Use Open source unit test frameworks
whenever available
• It is not impossible to write a simple
automated test framework or variant to fit
your needs
Thursday, 6 May 2010
32. 32
is TDD only for new projects?
• Identify change points
• Find test points
• Break dependencies
• Write tests
• Make changes and refactor
Thursday, 6 May 2010
33. 33
Fixing Broken Windows
• Talk to the developers individually about
what’s bothering them most to look for
really bad code and it’s too overwhelmed
to clean up
• Help them form a plan of action to
renovate the code
• Recognising the problem and breaking it
down into bite-size pieces
• Collective Code Ownership
Thursday, 6 May 2010
34. 34
I got hardware, can I... ?
• Dual targeting
• Run tests on development environment
• Run tests on real hardware to discover
differences, endian, memory models...
• OS abstraction layer
• Simulation layers
• Lots of stubs, plus dependency injection
• Learning tests
Thursday, 6 May 2010
35. 35
References
Working Effectively with Legacy Code 修改代码的艺术 -
Michael Feathers
Practical TDD and ATDD for Java Developers - Lasse Koskela
Clean Code 代码整洁之道 - Robert Martin
Practices for scaling Agile and Lean practices - Craig Larman
and Bas Vodde
Growing OO Software, guided by tests - Steve Freeman
xUnit Test Patterns - Gerard Meszaros
Agile Coaching - Rachel Davis and Liz Sedley
Thursday, 6 May 2010
