Intro To Tdd Agile Palooza

Introduction to Test-Driven Development Driving Software Design through Programmer Tests Chris Sterling Technology Consultant, Certified Scrum Trainer, and Agile Coach

Agenda • Test-Driven Development (TDD) – The “Flow” – Integrating with Team • Reasons for TDD • Difficulties with TDD • Example TDD Session • Refactoring 2 Copyright © 2009 SolutionsIQ. All rights reserved.

Test-Driven Development Basic “Flow” and Constructs of TDD

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 Copyright © 2009 SolutionsIQ. All rights reserved.

Test-Driven Development Integrating with Teams

Test-Driven Development Why Is TDD Important?

Managing Software Debt – an Overview Effect of Managing Software Debt over time is extended preservation of software’s value Higher Software Value Potential for depreciation is always there so discipline is essential Minimum Acceptable Value Time Copyright © 2009 SolutionsIQ. All rights reserved.

Acceptance Test-Driven Development Functional Implement Functionality Requirement Execute Draft Acceptance Test Cases Acceptance Test Cases Review Results Verify Results Accepted Modify Acceptance Test Cases 16 Copyright © 2009 SolutionsIQ. All rights reserved.

Test-Driven Development What Causes TDD to be so Difficult to Implement Well?

Impediments to TDD This simple technique for developing software, when used in a disciplined manner, will enable individuals and teams to improve software quality. The discipline necessary to do TDD is not easily attainable. Following is a list of environmental issues that lowers chances of effectively implementing TDD approach. 19 Copyright © 2009 SolutionsIQ. All rights reserved.

Schedule Pressure Pressure from management and stakeholders to release based on an unreasonable plan. Integrity of the software is always sacrificed when the plan is inflexible and unwilling to incorporate reality. 20 Copyright © 2009 SolutionsIQ. All rights reserved.

Lack of Passion Lack of passion for learning and implementing TDD effectively on Team. The amount of discipline required makes passion extremely helpful. 21 Copyright © 2009 SolutionsIQ. All rights reserved.

Insufficient Experience Insufficient team member ratio who have experience doing TDD well. When there is little experience on or coaching for the team success is minimal. 22 Copyright © 2009 SolutionsIQ. All rights reserved.

Legacy Code If the software’s design is poor or is difficult to test then finding a starting 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 time. 23 Copyright © 2009 SolutionsIQ. All rights reserved.

Introducing TDD Approach Effectively To successfully adopt TDD, it is important to manage these environmental issues. This could include managing expectations, providing the Team support from a coach, and enabling sufficient learning of tools and techniques while working with an existing code base. 24 Copyright © 2009 SolutionsIQ. All rights reserved.

Test-Driven Development Quick Example

Jitter – Example TDD Session • Fake micro-blogging tool named “Jitter” is made by Seattle-based fictitious 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 automatically expand common shorthand notation • The acceptance criteria for this user story are: – LOL, AFAIK, and TTYL are expandable – Able to expand lower and upper case versions of shorthand 26 Copyright © 2009 SolutionsIQ. All rights reserved.

Expand LOL to “laughing out loud” public class WhenUsersWantToExpandMessagesThatContainShorthandTest { @Test public shouldExpandLOLToLaughingOutLoud() { JitterSessionsession = mock(JitterSession.class); when(session.getNextMessage()).thenReturn(\"Expand LOL please\"); MessageExpanderexpander = 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 Copyright © 2009 SolutionsIQ. All rights reserved.

But wait…what if…? • What if LOL is written in lower case? • What if it is written as “Lol”? Should it be expanded? • What if some variation of LOL is inside a word? • What if characters surrounding LOL are symbols, not letters? Write these down as upcoming programmer tests as comments so I don’t forget them. // shouldExpandLOLIfLowerCase // shouldNotExpandLOLIfMixedCase // shouldNotExpandLOLIfInsideWord // shouldExpandIfSurroundingCharactersAreNotLetters 28 Copyright © 2009 SolutionsIQ. All rights reserved.

Expand LOL If Lower Case @Test public void shouldExpandLOLIfLowerCase() { when(session.getNextMessage()).thenReturn(\"Expandlol please\"); MessageExpanderexpander = new MessageExpander(session); assertThat(expander.getNextMessage(), equalTo(\"Expand laughing out loud please\")); } This forced use of java.util.regex.Pattern to handle case insensitivity. public String getNextMessage() { String msg= session.getNextMessage(); return Pattern.compile(\"LOL”, Pattern.CASE_INSENSITIVE) .matcher(msg).replaceAll(\"laughing out loud\"); } 29 Copyright © 2009 SolutionsIQ. 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); MessageExpanderexpander = new MessageExpander(session); assertThat(expander.getNextMessage(), equalTo(msg)); } This forced me to stop using Pattern.CASE_INSENSITIVE flag in pattern compilation. 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 Copyright © 2009 SolutionsIQ. 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); MessageExpanderexpander = new MessageExpander(session); assertThat(expander.getNextMessage(), equalTo(msg)); } The pattern matching is now modified to use spaces around each variation of valid LOL shorthand. return Pattern.compile(\"\\\\sLOL\\\\s|\\\\slol\\\\s\").matcher(msg) .replaceAll(\"laughing out loud\"); 31 Copyright © 2009 SolutionsIQ. All rights reserved.

Expand “LOL” If Not Inside Word @Test public void shouldExpandIfSurroundingCharactersAreNotLetters() { when(session.getNextMessage()).thenReturn(\"Expand .lol! please\"); MessageExpanderexpander = new MessageExpander(session); assertThat(expander.getNextMessage(), equalTo(\"Expand .laughing out loud! please\")); } The final implementation of pattern matching code looks as follows. return Pattern.compile(\"\\\\bLOL\\\\b|\\\\blol\\\\b\").matcher(msg) .replaceAll(\"laughing out loud\"); 32 Copyright © 2009 SolutionsIQ. All rights reserved.

Test-Driven Development Refactoring

Merciless Refactoring • Refactoring: a disciplined technique for restructuring an existing 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 * From http://www.refactoring.com/ 34 Copyright © 2009 SolutionsIQ. All rights reserved.

Where to Start Refactoring? • Does this change directly affect feature I am working on? • Would change add clarity for feature implementation? • Will change add automated tests where there are none? If “yes” to any question above, ask following question to decide if you should work on it now: • At first glance, does refactoring look like a large endeavor involving significant portions of the 35 Copyright © 2009 SolutionsIQ. 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 estimate 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 iteration without affecting delivery on our commitments then continue refactor • If refactoring affects commitments then bring it to Customer for discussion how to proceed 36 Copyright © 2009 SolutionsIQ. All rights reserved.

Automate Testing to Support Refactoring • Refactoring cannot be done effectively without automated tests surrounding code • Start by creating automated test which fails • If difficult to create at unit level look at automated acceptance tests from functional perspective • Over time look for ways to create automated unit tests 37 Copyright © 2009 SolutionsIQ. All rights reserved.

Principles of Agile Software Quality • The system always runs • No code is written without a failing test • Zero post-iteration bugs * From “Flawless Iterations” presented by Alex Pukinskis at Agile 2005 39 Copyright © 2009 SolutionsIQ. All rights reserved.

Thank you Questions and Answers

Chris Sterling • Technology Consultant, Certified Scrum Trainer and Agile Coach at SolutionsIQ • Consults on software technology across a spectrum of industries • Consults organizations on Agile development, management, and enterprise practices • Founder of International Association of Software Architects (IASA) Puget Sound chapter • University of Washington Lecturer: Agile Developer Certificate Program • Email: CSterling@SolutionsIQ.com • Blog: http://chrissterling.gettingagile.com 41 Copyright © 2009 SolutionsIQ. All rights reserved.

Intro To Tdd Agile Palooza

0 comments

Notes on slide 1

Favorites, Groups & Events