Intro To Tdd Agile Palooza
-
Upload
chris-sterling -
Category
Technology
-
view
1.034 -
download
3
description
Transcript of 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
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Ques>ons for You...
• How many of you are prac>cing TDD?
• What issues are you having currently with TDD?
3
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Test-‐Driven Development
Basic “Flow” and Constructs of TDD
4
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
TDD -‐ Basic “Flow”
5
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
TDD -‐ Basic “Flow”
5
Write Failing Test
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
TDD -‐ Basic “Flow”
5
Write Failing Test
Make Test Pass
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
TDD -‐ Basic “Flow”
5
Write Failing Test
Make Test Pass
Refactor to Acceptable Design
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
TDD -‐ Basic “Flow”
5
Write Failing Test
Make Test Pass
Refactor to Acceptable Design
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Test-‐Driven Development
Integra>ng with Teams
8
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Integra>ng with Team
9
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Integra>ng with Team
9
Write Failing Test
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Integra>ng with Team
9
Write Failing Test
Make Test Pass
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Integra>ng with Team
9
Write Failing Test
Make Test Pass
Integrate with Team
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Integra>ng with Team
9
Write Failing Test
Make Test Pass
Refactor to Acceptable Design
Integrate with Team
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Integra>ng with Team
9
Write Failing Test
Make Test Pass
Refactor to Acceptable Design
Integrate with Team
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Integra>ng with Team
9
Write Failing Test
Make Test Pass
Refactor to Acceptable Design
Integrate with Team
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Need-‐Driven Design
10
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Test-‐Driven Development
Why Is TDD Important?
11
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Accrual of Quality Debt
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Break/Fix Only Prolongs It
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Effect of Project Constraints on Quality
14
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Effect of Project Constraints on Quality
14
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Acceptance Test-‐Driven Development
16
FunctionalRequirement
Draft AcceptanceTest Cases
ImplementFunctionality
ExecuteAcceptance Test Cases
ReviewResults
Modify AcceptanceTest Cases
Verify Results
Accepted
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Con>nuous Integra>on
17
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Test-‐Driven Development
What Causes TDD to be so Difficult to Implement Well?
18
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Test-‐Driven Development
Quick Example
25
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Expand LOL If Lower Case
@Test
public void shouldExpandLOLIfLowerCase() {
when(session.getNextMessage()).thenReturn("Expand lol please");
MessageExpander expander = new MessageExpander(session);
assertThat(expander.getNextMessage(),
equalTo("Expand laughing out loud please"));
}
This forced use of java.u1l.regex.Pa6ern to handle case insensi1vity.public String getNextMessage() {
String msg = session.getNextMessage();
return Pattern.compile("LOL”, Pattern.CASE_INSENSITIVE)
.matcher(msg).replaceAll("laughing out loud");
}
29
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Don’t Expand “Lol” – Mixed-‐Case
@Test
public void shouldNotExpandLOLIfMixedCase() {
String msg = "Do not expand Lol please";
when(session.getNextMessage()).thenReturn(msg);
MessageExpander expander = new MessageExpander(session);
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() {
String msg = session.getNextMessage();
return Pattern.compile("LOL|lol").matcher(msg)
.replaceAll("laughing out loud");
30
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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);
MessageExpander expander = new MessageExpander(session);
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)
.replaceAll("laughing out loud");
31
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Expand “LOL” If Not Inside Word
@Test
public void shouldExpandIfSurroundingCharactersAreNotLetters() {
when(session.getNextMessage()).thenReturn("Expand .lol! please");
MessageExpander expander = new MessageExpander(session);
assertThat(expander.getNextMessage(),
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)
.replaceAll("laughing out loud");
32
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Test-‐Driven Development
Refactoring
33
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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/
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Automated Tests
38
Application
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Automated Tests
38
New Feature
Application
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Automated Tests
38
New Feature
Application
Design Changes
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Automated Tests
38
New Feature
Application
Design ChangesAutomatedRegressionTest Run
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Automated Tests
38
New Feature
Application
Design ChangesAutomatedRegressionTest Run
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
Thank you
Ques>ons and Answers
40
Friday, February 5, 2010
Copyright © 2010 Sterling Barton. All rights reserved.
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
Friday, February 5, 2010