driving quality with tdd

Driving Quality with TDD

Steven Mak 麥天志[email protected]

Thursday, 6 May 2010

mailto:[email protected]


http://www.odd-e.com


About me

• Steven Mak 麥天志• Agile Coach at Odd-e• Lives in Hong Kong• I do speak Mandarin!• Agile, TDD Coaching• Love to code


Agenda

• Why you care?• What you can do?• How to implement?


Sacrificing quality with Legacy Code

4


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


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

Valu

e co

de/d

esig

n qu

ality

Time

effo

rt n

eede

d fo

r ch

ange

Time


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


8

Professionalism


Test Driven Development

9


10

We need Unit Tests• New Functionality• Fix problems• Improve design• Optimise resources

• “Edit and Pray” or “Cover and Modify”?


11

Good Unit Tests• Fast• Localise problems• Readable• One assertion per tests

• Don’t forget higher level/Customer-facing tests


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)


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”)


14

What is Refactoring?

• A series of small steps, each of which changes the program’s internal structure without changing its external behaviour


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


16

• Duplicated Code• Long Method• Large Struct/Class• Long parameter list• Switch statements• Comments

Code Smells


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...?


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


19

Slow Build?

• Add hardware• Parallelize• Change tools• Incremental Build• Incremental Deployment• Manage dependencies


Can I start on the next Monday?

20


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!”






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


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


24

Coding Dojo


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!


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?


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


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


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


http://www.computer.org/cms/Computer.org/ComputingNow/homepage/2010/0110/W_SW_PairProgramming.pdf




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


31

Examples of UT frameworks

• C/C++ - CppUTest• Java - JUnit• .Net - NUnit• PHP - PHPUnit• Python - PyUnit• Ruby - Test::Unit, RSpec


32

is TDD only for new projects?

• Identify change points• Find test points• Break dependencies• Write tests• Make changes and refactor


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


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


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


36

Questions?

Steven Mak 麥天志[email protected]






driving quality with tdd

Technology