1.
Technical Practices in Agile-TDD
by
Prashant Pund
Certified SAFe Program Consultant
CSM, Agile Coach
AgileSoft Methodologies,Pune
prashant.pund@agilesoft.in
+919923073192
www.agilesoft.in

2.
Event Backlog
• Theme: Agile Technical Practices
• Epic: TDD implementation
• Stories:
1. Context of TDD
2. What is TDD
3. Response of Developers to TDD implementation
4. Practices complimenting TDD
5. Success with TDD
www.agilesoft.in

3.
Backlog…
• Stories:
1. Context of TDD
2. What is TDD
3. Response of Developers to TDD
implementation
4. Practices complimenting TDD
5. Success with TDD
www.agilesoft.in

4.
www.agilesoft.in
We are uncovering better ways of developing software by
doing it and helping others do it.
Through this work we have come to value:
• Individuals and interactions over processes and
tools
• Working software over comprehensive
documentation
• Customer collaboration over contract
negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we
value the items on the left more.
We follow these principles:
• Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
• Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
• Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
• Business people and developers must work
together daily throughout the project.
• Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
• The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
• Working software is the primary measure of
progress.
• Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
• Continuous attention to technical excellence
and good design enhances agility.
• Simplicity--the art of maximizing the amount
of work not done--is essential.
• The best architectures, requirements, and designs
emerge from self-organizing teams.
• At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behaviour accordingly.
TDD, DDD,
UML modeling,
BDD, Pair
Programming,
Refactoring
CI……..
Credit: www.agilemanifesto.org

5.
Change for Agile adoption-Our 3D
approach to implementation
www.agilesoft.in
Project Management
Technical Practices
Mindset
S
t
op

6.
Roles,Goals,Reasons
• PO: I want to get functionality implemented
so that I can get the business value.
• Developer: I want to write the code so that it
passes all the tests.
• Tester: I want to test the functionality so that
no defects go undetected.
We together want to develop
functionality so that PO gets
business value.

7.
Change in goal prompts change in
Technical Practices
• You move from Planned Development to
Evolutionary Incremental Development.
• Hence traditional practices such as Big Bang
Testing/Integration phase will not work.
www.agilesoft.in

8.
Backlog…
• Stories:
1. Context of TDD
2. What is TDD
3. Response of Developers to TDD
implementation
4. Practices complimenting TDD
5. Success with TDD
www.agilesoft.in

9.
Just to ensure that everyone is on the
same page….
www.agilesoft.in

10.
What is TDD?
• Useful practice of code development to have
simple, encapsulated, minimal, scalable code.
(Ron Jeffries says, “Clean Code that works”.)
• Input: User story
• Output: Accepted User story
• Process: Red-Green-Refactor
• Role: Developer
• Environment: Unit testing and coding
www.agilesoft.in

11.
Red Green Refactor
www.agilesoft.in
Write a
failing test
Make the
test pass
Refactor
Quickly add
a failing test
Make all the
tests pass
Refactor

12.
Backlog…
• Stories:
1. Context of TDD
2. What is TDD
3. Response of Developers to TDD
implementation
4. Practices complimenting TDD
5. Success with TDD
www.agilesoft.in

13.
Overheard about TDD in the pantry….
• Why should Test be the driver rather than Design?
• Give me the design… how can I write code without it?
Don’t tell me you don’t need to think of a class before
a method…
• Come on…I can see the whole logic…let me code it....
why tests?
• Writing tests every time is time-consuming.
• Worse is to see the test failing… what is there to see?
• By now, I could have finished with this code without
TDD.

14.
Backlog…
• Stories:
1. Context of TDD
2. What is TDD
3. Response of Developers to TDD
implementation
4. Practices complimenting TDD
5. Success with TDD
www.agilesoft.in

15.
TDD is not about only test first…
• It is about development as a whole.
Development involves whatever that is needed
to turn the Product Backlog into potentially
shippable product. (Ref: Scrum Guide) So, it
has coding and design and testing and build
and integration… associated with it.
• Do you remember, in XP, they say the practices
don’t work in isolation; they work in synergy.

16.
Practices that compliment TDD
• ATDD/BDD
• Refactoring
• Clean Code
• SOLID principles
• Design Patterns
• Design metrics (by static analysis)
• Emergent Design
• Domain Driven Design
• Continuous Integration
…. And perhaps more
www.agilesoft.in

17.
Backlog…
• Stories:
1. Context of TDD
2. What is TDD
3. Response of Developers to TDD
implementation
4. Practices complimenting TDD
5. Success with TDD
www.agilesoft.in

18.
Challenges in TDD implementations
• “It's probably the one thing we're struggling
the most with."
"We do a lot of unit and function test
automation in general, and we're getting
better with integration testing, but it's a
mindset! Developers like to develop code;
they don't necessarily like to test.”
-Sue McKinney, vice president of IBM's development
transformation

19.
Challenges in TDD implementations
• "We struggle with a large code base not written
using TDD. It's difficult to … be test-driven in a
legacy code base.”
• "I have concerns if it's doable in a code base not
designed to work that way. We have some
architectural issues before we get there. I'm not
philosophically opposed; I just don't want to
make our jobs harder.”
-Chris Kinsman, vice president and chief architect at AMS
Services, a provider of insurance agency automation products

20.
What does it take to succeed with TDD
• Input: User story--- Acceptance
Criteria/Scenarios
• Output: Accepted User story--- Know the DoD
• Process: Red-Green-Refactor---Environment
supporting the Process like Xunit, Static
Analysis Tool, Refactoring support
• Role: Developer--- Acquire skills
• Environment: Unit testing and coding–
Combine with CI, ATDD/BDD
www.agilesoft.in

21.
Input
• Do you have Acceptance Criteria or Scenarios
written for the User Story under
development? (The third C-Confirmation of
US) Want to use tools for it?
• Do you think the format Given-when-then
gives you better retention of understanding?
• How much is the doubt about the User Story?
www.agilesoft.in

22.
Output
• Do you have the Acceptance Criteria and
Definition Of Done for the user story?
• Do you have the opportunity to show the
developed user story to PO and seek the
feedback?
www.agilesoft.in

23.
Process
• Do you have the macro cycle of ATDD around the
Unit TDD?
• Do you watch the test failing?
• Oh, do you REALLY write a test before code?
• Do you know how to write effective and efficient
test cases ?
• Do you REALLY refactor the code before adding
next functionality or are you happy with Green
bar? (Do you have the guts to change the code
that has passed the tests?)
www.agilesoft.in

24.
Role: Behavior of Developers forced to
TDD
• Writing huge code as the logic is understood
• Failure to refactor as the code is “WORKING”
• Writing tests initially (religiously) and then
continuing without them to create larger codes.
• Believing that the TDD is time consuming as the
“FULL & FINAL” code can be seen only later.
• I am OK with the present; change is a
disturbance! (Inertia due to comfort zone)
• What is in it for me?- WIIFM the famous
marketing phrase
www.agilesoft.in

25.
Role: Developer’s Skills for TDD
• Refactoring Patterns
• SOLID principles
• GOF Design Patterns
• Clean Code
www.agilesoft.in

26.
Refactoring
• In case of TDD, the code refactoring as well as
design level refactoring is needed. As the code
gets added, the design evolves; a higher
abstraction level refactoring becomes necessary.
• Code level refactoring: long method, naming of
methods/parameters which make code
“readable”
• Design Refactoring: As the functionality gets
added, we need to leave the “design”(not just the
design of code, real “design”) in the simplest
possible, scalable state.

27.
Example of code refactoring
Before
double getPrice() {
int basePrice = _quantity *
_itemPrice;
double discountFactor;
if (basePrice > 1000)
discountFactor = 0.95;
else discountFactor = 0.98;
return basePrice *
discountFactor;
}
After
double getPrice() {
return basePrice() *
discountFactor();
}
www.agilesoft.in

28.
Design Refactoring
• It may perhaps start only with a few simple
techniques like extract interface, extract class
etc and further may use SOLID principles and
further, Design Patterns.

29.
Example of Design Refactoring
www.agilesoft.in
Before After

30.
Environment
• Do you have CI environment set up?
• Does your development environment allow
you quick and easy refactoring?
www.agilesoft.in

31.
Typical CI set up
credit: Continuous Integration , book by Paul Duvall page 26
www.agilesoft.in

32.
Other challenges…
• How do I convince my manager on the cost of
TDD….say on environment and time?
• We have schedule pressure, the PO won’t
allow the time investment
• We don’t develop new code; we maintain
legacy system…where does TDD fit in?
www.agilesoft.in

33.
Probable answers
• Unfortunately we are driven more by external
data than own experience. You can’t convince
someone across the table on methodology. But
perhaps, better design metrics and reduction in
defect injection can help convince.
• For existing system, Michael Feathers has
discussed the development approach in his
famous book, “Working effectively with Legacy
code” where TDD is a part of the approach.
www.agilesoft.in

34.
The Legacy Code Change Algorithm
1. Identify change points.
2. Find test points.
3. Break dependencies.
4. Write tests.
5. Make changes and refactor.

35.
Case study: Legacy System
Changes needed
In these methods
Credit: Working Effectively
with Legacy Code-Michael Feathers
Fig2.1 and 2.2

36.
Isolating for tests
• We need to know the collaborators, in this case
InvoiceUpdateServlet and DBConnection
• You need their objects but setting them for
testing purpose can be time-consuming and
costly.
• Fake DBConnection by extracting interface (and
introducing Fake object of DBConnection)
• Provide data ListInvoiceIDs from
InvoiceUpdateServlet instead of the whole
object.
www.agilesoft.in

37.
Case Study: Legacy Code
Interface extracted
Credit: Working Effectively
with Legacy Code-Michael Feathers
Fig2.1 and 2.2

38.
Backlog…
• Stories:
1. Context of TDD
2. What is TDD
3. Response of Developers to TDD
implementation
4. Practices complimenting TDD
5. Success with TDD
www.agilesoft.in

39.
prashant.pund@agilesoft.in
+919923073192
www.agilesoft.in