1. Test Driven Development
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
3. Overview and Introduction
4. • TDD is the most misunderstood practice in Agile / Xtreme
• Best practices starts with clearing the notion of what exactly is
• Needs a mindset change at all levels
• 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
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.
•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
•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.
10. TDD Learning / Best Practices to Sustain
- 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
•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
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
receiveAndProcessOrder(..) instead of processMessage(..)
15. [Best] Practices to Sustain TDD – People & Process
• A ~3 week Induction
program for each
• To cover aspects
related to Test Driven
• Workshops to further
ingrain the “Best
• 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,
• 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
16. TDD Frameworks & Variations
17. TDD Frameworks
Category Name Description Suited For
Unit test JUnit
Simple Framework to write
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
JSFUnit JSFUnit is a test framework for
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 /
Mocking frameworks Powermock is an extension of Mockito.
Matcher Hamcrest Framework for writing matcher
• UI validation; built to use with Junit 3, 4.
• Jmock constraints are Hamcrest matchers.
• Adaptors are available for easymock as well.
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
Java GUI testing framework Swing, Dynamic HTML(Ajax) including GWT.
Shale Provides mock objects libraries JSF
BDD JBehave Framework for BDD. Built on
Java; very good documentation.
Simple and fast. Supports story
Suited for BDD / Java projects – easier for ones
BDD Cucumber Similar to jBehave. Built over
Ruby. Cucumber-JVM is the java
version. Supports feature level
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.
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
• 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
• BDD revolves around
• stories, that represent
executable increment of
• Stories include one to many
• Scenario represents a concrete
behavior of the system
20. Q & A
21. Market Research on TDD
Team Size 9 6 5-8 7
Redmond, WA Redmond, WA Redmond, WA
> 10 Years
6 - 10 Years
< 5 Years
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),
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
• 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