This document outlines an agenda for a presentation on Test Driven Development (TDD) best practices. The agenda includes sections on an overview and introduction to TDD, what TDD is and the process, challenges of TDD, learning and best practices for sustaining TDD, frameworks and variations of TDD, and a question and answer period. Some key best practices discussed are writing tests before code, focusing tests on functionality rather than code structure, and establishing governance and training to ensure proper adoption of TDD.

1. Test Driven Development
Best Practices
Ganesh Kondal
Principal Architect
May 21, 2013

2. 1. Overview and Introduction
2. TDD – What is it & Process
3. TDD Challenges
4. TDD Learning / Best Practices
5. TDD Frameworks & Variations
6. Q & A
Agenda

3. Overview and Introduction

4. • TDD is the most misunderstood practice in Agile / Xtreme
programming.
• Best practices starts with clearing the notion of what exactly is
TDD.
• Needs a mindset change at all levels
• People
• Processes - Continuous Delivery
• Coding practices.
• TDD is not just to find defects – but to give feedback on – quality
of the implementation (“Does it work”) and design (“Is it well
structured?”)
Overview and Introduction

5. TDD – What is it & Process

6. • Golden Rule - “ Write a failing unit test. “
• Why so? You don’t have any code to satisfy it
• Focusses on what needs to be done. “intent”
• Process of TDD
• The Bigger Picture
• Begins each feature with a failed acceptance tests
• Avoid starting with unit tests for classes
[ testing boundary errors, wrong boolean expressions etc.,]
What is it & TDD Process
• First, build a “walking-skeleton”
• Implementation of the thinnest possible slice of real functionality that we can automatically
build, deploy, and test end-to-end
• End-to-end testing at the start, for better/working system design
• Expose Uncertainty early – flush issues when there is time / goodwill / budget

7. • Acceptance Tests are to
• Look from user point of view, before the implementers [class level tests]
• Teams’ progress are seen as acceptance tests turn – red to green.
• Different JUnit test suites (one for acceptance, one for regression)
• Writing Tests – is a “design work” in TDD
• Mock vs. stub -
• Objects pre-programmed with expectations which form a specification of the calls they
are expected to receive.
• Stubs provide canned answers to calls made during the test
What is it & TDD Process

8. TDD Challenges

9. •People are resistant to change.
•People don’t know about TDD.
•It will take too long to learn how to do TDD correctly.
•We don’t know where to start; We can’t test our codebase.
People
•TDD takes a lot of practice, than it really is.
•TDD takes way more time, without giving any real benefit.Perception
•Adopting TDD for legacy applications.
•Writing / maintaining tests takes time and effort.
•Maintaining the test speed is vital. Slow tests demotivates test
execution.
•Needs constant care : else tests become brittle and fail.
•User interfaces, real-time, and embedded software don’t lend
themselves as naturally to TDD.
•Setting up back-end components and precisely controlling
their state inside automated tests requires care.
•Unit testing concurrency.
Technology
TDD Challenges

10. TDD Learning / Best Practices to Sustain
- Technology
- People & Process

11. •Multiple runs of the test should consistently return true or
consistently return false, provided no code changes were made.Consistent
•Only two possible results: PASS or FAILAtomic
•One test should be responsible for one scenario only. [Single
responsibility principle]Isolation
•Unit test must be easy to read and understandSelf Descriptive
•Unit tests should not be interdependentIndependent
•Should communicate the intent.
•Unit tests are great design/usage ‘docs’)Communicative
•Ensure the test setup and execution is easy and fast.Setup & Execution
[Best] Practices to Sustain TDD – Technology

12. • Listen to tests
• Bloated constructors – shows multiple responsibility; complicated design
• Assign Defaults
[Best] Practices to Sustain TDD – Technology cont.

13. [Best] Practices to Sustain TDD – Technology cont.
• Test Readability
• Tests are to test the features / capability – not blindly to test few lines of code (or
an API per se.,)
• Test names should describe features
• No exception handling OR un-necessary assertions/fail(s)
• assertFalse is better (readable than a ) assertTrue with !
• Name variables to show the role they play
• Ensure test / source code are in different folders

14. [Best] Practices to Sustain TDD – Details contd.,
• Use ‘object mother’ to build complex test objects
• Tests need to communicative – small, focused and well named
• Let assertion failures be more meaningful
• When using mock objects, always ensure, you check the expectations were met.
• Make diagnostics clear – else while you refactor the code, you will not know –when
a test fails for a wrong reason (than expected ways)
• Precise Assertions, Expectations
• Avoid asserting aspects that are not relevant. getCustomerById( customerID ) -
ensure the customer has the ID passed; avoid checking the customers’ name for
example.
receiveAndProcessOrder(..) instead of processMessage(..)

15. [Best] Practices to Sustain TDD – People & Process
• A ~3 week Induction
program for each
incoming associate
• To cover aspects
related to Test Driven
Development,
Libraries &
Frameworks
• Workshops to further
ingrain the “Best
Practices”
• Govern the adoption of TDD –
with code checks.
• Ensure the team has understood
the practices and tools correctly,
and using them effectively.
• Set simple goals.
• Keep a check – to avoid (artificial)
pressures to ship product soon.
• Utilize TDD Tools, mocking frameworks,
BDD/ATDD frameworks.
• Ensure to get feedback, on usage, issues
– as often as possible.
• Monitor & Analyze
impact at individual
level & overall Project
level – via metrics
• Identify Gap Areas &
address the same on a
priority basis
TDD
Induction,
KT &
Workshops
Governance
Body
Libraries &
Frameworks
Evaluation
Model

16. TDD Frameworks & Variations

17. TDD Frameworks
Category Name Description Suited For
Unit test JUnit
HttpUnit
Simple Framework to write
repeatable tests
Instance of xUnit architecture
JUnit 4.8.2 ships with Hamcrest
HttpUnit – is a stalled project.
DBUnit Junit extension Database is put into a known state before/after
runs.
JSFUnit JSFUnit is a test framework for
JSF applications
Allows complete integration testing and unit
testing of JSF applications using a simplified API.
Uses Arquillian [ Jboss Test Framework ]
TestNG Similar to JUnit and NUnit
Mocks Mockito /
Jmock /
EasyMock /
Powermock
Mocking frameworks Powermock is an extension of Mockito.
Matcher Hamcrest Framework for writing matcher
objects
• UI validation; built to use with Junit 3, 4.
• Jmock constraints are Hamcrest matchers.
• Adaptors are available for easymock as well.
TC
Generator
CodePro Eclipse plugin Static analyzer and Junit test code generator. Will
be useful for jumpstarting legacy applications

18. TDD Frameworks
Category Name Description Suited For
UI Window
licker
Java GUI testing framework Swing, Dynamic HTML(Ajax) including GWT.
Test
Framework
Shale Provides mock objects libraries JSF
Servlet
BDD JBehave Framework for BDD. Built on
Java; very good documentation.
Simple and fast. Supports story
level testing.
Suited for BDD / Java projects – easier for ones
using Maven.
BDD Cucumber Similar to jBehave. Built over
Ruby. Cucumber-JVM is the java
version. Supports feature level
tests.
Suited for BDD projects. Can use Selenium Web
Drivers for UI feature testing aspects.
Selenium For Browser automation Selenium Web Driver for automated Scripts
Selenium IDE for quick record and replay tasks.
Testing
Platform
Arquillian A test framework that can be
used to perform testing inside a
remote or embedded container,
or deploy an archive to a
container so the test can
interact as a remote client;
Under evaluation. From JBoss community

19. TDD Variations
• ATDD
• Criteria specified by the
customer are automated into
acceptance tests, which then
drive the traditional TDD
• BDD [Evans03]
• Combines TDD Principles with
ideas from domain-driven design
to provide software developers
and business analysts with
shared tools and a shared
process.
• BDD revolves around
• stories, that represent
executable increment of
business functionality.
• Stories include one to many
scenarios
• Scenario represents a concrete
behavior of the system

20. Q & A

21. Market Research on TDD
Metric description
IBM:
Drivers
Microsoft:
Windows
Microsoft :
MSN
Microsoft :
VS
Team Size 9 6 5-8 7
Team Location
USA and
Mexico
Redmond, WA Redmond, WA Redmond, WA
Experience Level
> 10 Years
6 - 10 Years
< 5 Years
0
3
6
0
5
1
1
7
0
5
0
2
Domain Expertise [Low (L), Medium (M), High (H)] M - L H M H
Language Expertise [Low (L), Medium (M), High (H)] M - L H M H
Programming Language Java C/C++ C++/C# C#
Program Manager’s Experience [Low (L), Medium (M),
High (H)]
H H M M
Team Location Distributed Collocated Collocated Collocated

22. TDD Benefits

23. TDD Benefits
• TDD – is a design tool
• Writing your test first makes you think of the software you are writing as a user of
that software.
• Drives the design and development to focus on what needs to be done – alone.
• Eases Programmers life
• Provides constant / instantaneous feedback / documentation at component level.
• Proof your code works; fewer bugs & mainly ‘Peace of mind’
• Eases the ability to change
• The software tends to be loosely coupled and easily maintainable, cause the
developer is free to make design decisions and “Freedom to refactor without fear”
• Regression safety net on bugs:
• If a bug is found, the developer should create a test to reveal the bug and then
modify the production code so that the bug goes away and all other tests still pass.
• Always coding towards a goal to reach
• Never write code than what is required!
• Reduced defect density