intro to tdd agile palooza

Introduc)on to Test-‐Driven DevelopmentDriving So7ware Design throughProgrammer Tests

Chris SterlingTechnology Consultant, Cer)fied Scrum Trainer, and Agile Coach

Friday, February 5, 2010

Copyright © 2010 Sterling Barton. All rights reserved.

Agenda

• Test-‐Driven Development (TDD)–The “Flow”– Integra)ng with Team

• Reasons for TDD

• Difficul>es with TDD

• Example TDD Session

• Refactoring

2



Ques>ons for You...

• How many of you are prac>cing TDD?

• What issues are you having currently with TDD?

3



Test-‐Driven Development

Basic “Flow” and Constructs of TDD

4



TDD -‐ Basic “Flow”

5




5

Write Failing Test




5

Write Failing Test

Make Test Pass




5

Write Failing Test

Make Test Pass

Refactor to Acceptable Design



Steps of TDD “Flow”

1. Write a programmer test

2. Run the programmer test and it should fail (red bar)

3. Write just enough code to make failing test pass

4. Run programmer test successfully (green bar)

5. Refactor code to an acceptable design (green bar)

RISK: Pushing out refactoring to add more code first. Don’t forget to refactor frequently to an acceptable design.

6



Be a User -‐-‐“What should the so^ware do next for me?”

This ques>on helps you to decide what the next programmer test should model

7




Integra>ng with Teams

8



Integra>ng with Team

9




9

Write Failing Test




9

Write Failing Test

Make Test Pass




9

Write Failing Test

Make Test Pass

Integrate with Team




9

Write Failing Test

Make Test Pass

Refactor to Acceptable Design

Integrate with Team



Need-‐Driven Design

10




Why Is TDD Important?

11



Accrual of Quality Debt



Break/Fix Only Prolongs It



Effect of Project Constraints on Quality

14



Managing So^ware Debt – an Overview

Minimum Acceptable

Value

Depreciation ofValue Due to

Software Debt

Time

Effect of Managing Software Debtover time is extended preservationof software’s value

Hig

her S

oftw

are

Valu

e

Potential for depreciation is always there so

discipline is essential



Acceptance Test-‐Driven Development

16

FunctionalRequirement

Draft AcceptanceTest Cases

ImplementFunctionality

ExecuteAcceptance Test Cases

ReviewResults

Modify AcceptanceTest Cases

Verify Results

Accepted



Con>nuous Integra>on

17




What Causes TDD to be so Difficult to Implement Well?

18



Impediments to TDD

This simple technique for developing so^ware, when used in a disciplined manner, will enable individuals and teams to improve so^ware quality. The discipline necessary to do TDD is not easily aeainable. Following is a list of environmental issues that lowers chances of effec>vely implemen>ng TDD approach.

19



Schedule Pressure

Pressure from management and stakeholders to release based on an

unreasonable plan. Integrity of the so^ware is always sacrificed when the plan is inflexible and unwilling to incorporate

20



Lack of Passion

Lack of passion for learning and implemen>ng TDD effec>vely on Team. The amount of discipline required makes

passion extremely helpful.

21



Insufficient Experience

Insufficient team member ra>o who have experience doing TDD well. When there is liele experience on or coaching for the

team success is minimal.

22



Legacy Code

If the so^ware’s design is poor or is difficult to test then finding a star>ng point could seem impossible. If legacy code is large and contains

no, or only minimal, test coverage then disciplined TDD will not show visible results for

some >me.23



Introducing TDD Approach Effec>vely

To successfully adopt TDD, it is important to manage these environmental issues. This could include managing expecta>ons, providing the Team support from a coach, and enabling sufficient learning of tools and techniques while working with an exis>ng code base.

24




Quick Example

25



Jieer – Example TDD Session

• Fake micro-‐blogging tool named “Jieer” is made by Seaele-‐based fic>>ous company that focuses on enabling coffee injected folks to write short messages and have common online messaging shorthand expanded for easy reading. The user story we are working on is:

So it is easier to read their kid’s messages, Mothers want to automa>cally expand common shorthand nota>on

• The acceptance criteria for this user story are:–LOL, AFAIK, and TTYL are expandable–Expand lower and upper case versions of shorthand

26



Expand LOL to “laughing out loud”

public class WhenUsersWantToExpandMessagesThatContainShorthandTest {

@Test

public void shouldExpandLOLToLaughingOutLoud() {

JitterSession session = mock(JitterSession.class);

when(session.getNextMessage()).thenReturn("Expand LOL please");

MessageExpander expander = new MessageExpander(session);

assertThat(expander.getNextMessage(),

equalTo("Expand laughing out loud please"));

}

}

public class MessageExpander {

public String getNextMessage() {

String msg = session.getNextMessage();

return msg.replaceAll("LOL", "laughing out loud");

}

27



But wait…what if…?

• What if LOL is wrieen in lower case?

• What if it is wrieen as “Lol”? Should it be expanded?

• What if some varia>on of LOL is inside a word?

• What if characters surrounding LOL are symbols, not leeers?

Write these down as upcoming programmer tests as comments so I don’t forget them.

// shouldExpandLOLIfLowerCase

// shouldNotExpandLOLIfMixedCase

// shouldNotExpandLOLIfInsideWord

// shouldExpandIfSurroundingCharactersAreNotLetters

28



Expand LOL If Lower Case

@Test

public void shouldExpandLOLIfLowerCase() {

when(session.getNextMessage()).thenReturn("Expand lol please");



equalTo("Expand laughing out loud please"));

}

This forced use of java.u1l.regex.Pa6ern to handle case insensi1vity.public String getNextMessage() {


return Pattern.compile("LOL”, Pattern.CASE_INSENSITIVE)

.matcher(msg).replaceAll("laughing out loud");

}

29



Don’t Expand “Lol” – Mixed-‐Case

@Test

public void shouldNotExpandLOLIfMixedCase() {

String msg = "Do not expand Lol please";

when(session.getNextMessage()).thenReturn(msg);


assertThat(expander.getNextMessage(), equalTo(msg));

}

This forced me to stop using Pa6ern.CASE_INSENSITIVE flag in pa6ern compila1on. Only use “LOL” or “lol” for replacement criteria.

public String getNextMessage() {


return Pattern.compile("LOL|lol").matcher(msg)

.replaceAll("laughing out loud");

30



Don’t Expand “LOL” If Inside Word

@Test

public void shouldNotExpandLOLIfInsideWord() {

String msg = "Do not expand PLOL or LOLP or PLOLP please";

when(session.getNextMessage()).thenReturn(msg);


assertThat(expander.getNextMessage(), equalTo(msg));

}

The pa6ern matching is now modified to use spaces around each varia1on of valid LOL shorthand.

return Pattern.compile("\\sLOL\\s|\\slol\\s").matcher(msg)


31



Expand “LOL” If Not Inside Word

@Test

public void shouldExpandIfSurroundingCharactersAreNotLetters() {

when(session.getNextMessage()).thenReturn("Expand .lol! please");



equalTo("Expand .laughing out loud! please"));

}

The final implementa1on of pa6ern matching code looks as follows.return Pattern.compile("\\bLOL\\b|\\blol\\b").matcher(msg)


32




Refactoring

33



Merciless Refactoring

• Refactoring: a disciplined technique for restructuring an exis>ng body of code, altering its internal structure without changing its external behavior.*

• Merciless: having or showing no [mercy -‐ showing great kindness toward the distressed]

• Relieve your distressed code through kindness and disciplined restructuring

34* From http://www.refactoring.com/


http://www.refactoring.com

http://www.refactoring.com


Where to Start Refactoring?

• Does this change directly affect feature I am working on?

• Would change add clarity for feature implementa>on?

• Will change add automated tests where there are none?

If “yes” to any ques>on above, ask following ques>on to decide if you should work on it now:

• At first glance, does refactoring look like a large endeavor involving significant por>ons of the so^ware’s components?

35



When to Stop Refactoring?

• Am I refactoring code not directly affected by feature?

• Is other code directly affected by feature I am working on that has not been refactoring sufficiently?

• If refactoring is exploding feature es>mate given to Customer then I should bring it up to Team to decide how we should progress

• If Team decides that refactoring can be absorbed into current itera>on without affec>ng delivery on our commitments then con>nue refactor

• If refactoring affects commitments then bring it to Customer for discussion how to proceed

36



Automate Tes>ng to Support Refactoring

• Refactoring cannot be done effec>vely without automated tests surrounding code

• Start by crea>ng automated test which fails

• If difficult to create at unit level look at automated acceptance tests from func>onal perspec>ve

• Over >me look for ways to create automated unit tests

37



Automated Tests

38

Application



Automated Tests

38

New Feature

Application



Automated Tests

38

New Feature

Application

Design Changes



Automated Tests

38

New Feature

Application

Design ChangesAutomatedRegressionTest Run



Principles of Agile So^ware Quality

• The system always runs

• No code is wrieen without a failing test

• Zero post-‐itera>on bugs

39

* From “Flawless Iterations” presented by Alex Pukinskis at Agile 2005



Thank you

Ques>ons and Answers

40



Chris Sterling

• Technology Consultant, Cer>fied Scrum Trainer and Agile Coach at Solu>onsIQ

• Consults on so^ware technology across a spectrum of industries

• Consults organiza>ons on Agile development, management, and enterprise prac>ces

• Founder of Interna>onal Associa>on of So^ware Architects (IASA) Puget Sound chapter

• University of Washington Lecturer: Agile Developer Cer>ficate Program

• Email: CSterling@Solu>onsIQ.com

• Blog: hep://chrissterling.gepngagile.com

41


mailto:[email protected]

mailto:[email protected]

http://chrissterling.gettingagile.com/

http://chrissterling.gettingagile.com/

intro to tdd agile palooza

Technology

sterling barton

tddbasicflow5 copyright

sode bt discipline