Search

Successful Teams are Test-Driven Teams

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    How many testers?How many devs?How many managers?Non- New- Old-timer- Agilists?

    Iterations imply incremental developmentChange can result in a negative feedback loop - ENTROPYOr a positive one – EXERCISEWe have to address this. It’s not easy, until it becomes easy. At first, we’d rather not check the oil…

    Teams get Uncompromising Quality and Adaptability viaTDD

    We’re talking about a single coding event (story?) and it’s test. If the coding cycle is months, then the delay could be months.The developer will have forgotten. The BA/PO may have forgotten, too! Where do we gain value from testing? Running the test, or writing it?

    If you have to think about how you’d interact with the product, what are you doing? [Analysis]This is the final detailed analysis of a story before AND WHILE it’s being implemented. JIT Analysis!

    Tells you when a task is done, and done correctly.Reduces defects by detecting regression failures immediately.Much less time troubleshooting and re-testing.Relieves the Agilist’s Dilemma.Old NO notes:Each test is used to clarify what needs to be doneThe test then tells us when we got it rightSimultaneously, it tells us that we are done with that partEach test remains as an individual investment in the behavior and the quality of the designThe suite of tests preserves all prior behavior while we address design, allowing for Emergent DesignsThe test cases are documentation of the intentions, uses, and interfaces of the production codeFor DevelopersBugs are easier and faster to fix while they’re freshBugs are found and fixed before other dependent code is writtenFewer returns from QA, more time spent on developing not fixingFor TestersSpend more time on more critical testing (not finding and validating defects)For the Whole TeamDaily measurable progressProduct health and flexibilitySanity in the workplace and enjoyable work

    Developers don’t spend the minute to look for and clean up a new bit of code duplication.inexperienced coaches who confuse the developer-style TDD with the team ATDDwaffling over the use of TDD, which limits its effectiveness

    Habit: 30-days, support-groupBenefits org, team, individualDiscipline prevents regret (debt).

    “approximately 40% fewer defects” Laurie Williams for ACM

    Story 15 years old, at least (Phoenix).Truck stuck.Fire dept and others arrive and try to figure out what to do.Anecdotally, a young man walks up and says “Why not deflate the tires?”Developers can think about a problem and come up with a possible solution.BUT…first specify the question (Jeopardy-style)

    Microsoft and IBM…

    This is how we usually see our software. We point-click-type-point-click-type.Anything wrong with this?

    Test what’s important. This is not unit-testing. Think of it as conceptual coverage. What if you didn’t know (or care) what section of CODE you’re testing, but what STORY (BUSINESS VALUE).Not “Test the database” but “Test that user data gets stored safely and accurately.”Not “test the 3rd party web service connection” but “Test that we interact correctly with our partners.”

    Testing can’t be INCONCEIVABLE. Turing showed us that there’s no magic. Just about any test can be automated. Some vendors have added impossible-to-test magic back in (fat GUIs), but the agile/testing community is forcing even the giants (Sun, Microsoft) to rethink their architectures.And it’s often quite possible, and legitimate, to circumvent the magic. Sometimes we have to reconsider: What is the essence of this test???

    Translator between business object and what the Fit test is expecting to see. Adapter/Proxy, but it could match exactly. Usually some bit of translation required.

    start begins sequence; enter sets values; press executes action; check tests values.

    The word “error” in the cell tells Fit that the cell gets a PASSING grade if the call throws an exception.

    Create “setup” tables where necessary.

    If you use something like TortoiseSVN, then be sure to use the TortoiseSVN context menu consistently to rearrange things.

    Recall that we have a setup file at the top level in my testsYou can put tables into these setup.html files to animate order of execution

    Replacement for using ColumnFixture with a dummy column

    Replacement for ActionFixtureIf first, a “flow” style is allowed on the page…

    “Flow” style allows other fixtures anywhere after DoFixture is invoked.Actions themselves can be tested for errors by preceding the action with a “reject” or “not” cell.

    Each test remains as an individual investment in the behavior and the quality of the design

    In other words, design classes and methods so they do not have to change.Misinterpreted as “Subclass to enhance”, perhaps resulting in decades of inappropriate object designThankfully the GoF pointed out our mistake in Design Patterns

    Yeah, but in separate steps. Rather than hacking it in, TDD encourages us to alter design without altering behavior, then adding behavior.

    Google, Yahoo, MapQuest, and some others…Map is accessing some interface, plus it’s doing a lot of stuff with that data

    We’verefactored to OCP

    More classes, but no more code.

    1 Favorite

    Successful Teams are Test-Driven Teams - Presentation Transcript

    1. Successful Teams are Test-Driven Teams Better Software 11 June 2009 12 June 2009 © Rob Myers 2009 1
    2. DILBERT: © Scott Adams/Dist. by United Feature Syndicate, Inc. 12 June 2009 © Rob Myers 2009 2
    3. Rob Myers • Rob.Myers@agileInstitute.com • Teaching Agile courses since 2002 • XP/Agile coach since 1999 • Using TDD to build software since 1998 • Professional software development since 1986 • Blog: PowersOfTwo.agileInstitute.com 12 June 2009 © Rob Myers 2009 3
    4. History of TDD • Codified by Kent Beck. • From his XP practices. • Led to automated unit-test frameworks and refactoring tools. • Refined by Agilists into two distinct practices. 12 June 2009 © Rob Myers 2009 4
    5. The Agilist’s Dilemma 12 June 2009 © Rob Myers 2009 5
    6. Debt • Quality Debt • Defects • Design Debt • Software design resists change • Testing Debt • Manual testing http://tinyurl.com/dx2dka 12 June 2009 © Rob Myers 2009 6
    7. TEST-DRIVEN When Mediocrity Is Not Acceptable 12 June 2009 © Rob Myers 2009 7
    8. 1. Automation • Fast • Repeatable results • An improvement over… public static void Main() { Console.WriteLine( “I sure hope this works...” + myObject.Foo()); } 12 June 2009 © Rob Myers 2009 8
    9. 2. Test-First • We write a test before we write the code that makes it pass. • How do we do that? • Why do we do that? 12 June 2009 © Rob Myers 2009 9
    10. Why Wait? Code Months Test Code Weeks Test Code Days Test Code Test 12 June 2009 © Rob Myers 2009 10
    11. What If? Write Test Run Test Test Code Run Test Run Test 12 June 2009 © Rob Myers 2009 11
    12. Benefits of Test-First 1. Just-In-Time analysis. 2. We know when something is… • …done. • …done correctly. • …broken. • …and fixed! 12 June 2009 © Rob Myers 2009 12
    13. 3. Refactoring Any behavior- preserving change that improves maintainability. 12 June 2009 © Rob Myers 2009 13
    14. “Move Mount Fuji” 12 June 2009 © Rob Myers 2009 14
    15. Two Great Flavors TDD ATDD • Each test pins down • Each test pins down a technical behavior. business rule. • Written by developers. • Written by the team. • For developers. • For the team. • Run frequently by the • Run frequently by the team. team. • All tests pass 100% • New tests fail until the during integration. story is done. Old tests should all pass. “Peanut Butter Cup” by Laura Godi 12 June 2009 © Rob Myers 2009 15
    16. Architectural Benefits TDD ATDD • Encourages isolation • Forces team to think of orthogonal issues. about usability and behavior separately. • Allows patterns to • Encourages arise through MVC/MVP, separation refactoring. of concerns. • “External” concerns • Independent can be encapsulated automated tests can and tested check performance independently. metrics, security violations, etc. 12 June 2009 © Rob Myers 2009 16
    17. Roadblocks to Adoption • Developers skip refactoring. • Coaches confuse TDD with ATDD. • Managers waffle. • …and others. 12 June 2009 © Rob Myers 2009 17
    18. Discipline • A habit… • We still use when times are tough… • Because we know there is a long-term benefit. 12 June 2009 © Rob Myers 2009 18
    19. TEST-DRIVEN DEVELOPMENT Developers testing? No, and yes. 12 June 2009 © Rob Myers 2009 19
    20. What to do? 12 June 2009 © Rob Myers 2009 20
    21. Test-Driven Development: The Moves 1. Write one unit test. 2. Build or add to the object under test until everything compiles. 3. Red: Watch the test fail! 4. Green: Make all the tests pass by changing the object under test. 5. Refactor: Mercilessly! 6. Repeat. 12 June 2009 © Rob Myers 2009 21
    22. Developer’s “Oath of Athens” Leave the code as good as you found it, or better! 12 June 2009 © Rob Myers 2009 22
    23. Does TDD Work? “The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.” http://research.microsoft.com/en- us/projects/esm/nagappan_tdd.pdf, Nagappan et al, © Springer Science + Business Media, LLC 2008 12 June 2009 © Rob Myers 2009 23
    24. ACCEPTANCE-TEST DRIVEN DEVELOPMENT (ATDD) Driving Progress by Example 12 June 2009 © Rob Myers 2009 24
    25. The Story: Jim’s Personal Investment Performance Given certain past transactions, Jim’s current personal average annual return for LunEx Interplanetary Index in his retirement account is 6.25% 12 June 2009 © Rob Myers 2009 25
    26. A Workflow Test-Script • Select “My Account.” • Enter username “Jim.” • Enter password “password.” • Select Jim’s retirement account. • Select LunEx Interplanetary Index fund. • Press the “My performance” button. • Check that his personal average annual return is currently 6.25%. 12 June 2009 © Rob Myers 2009 26
    27. Interface-Centric • Slow. • Difficult to set up. • Numerous failures from one defect. • Failures do not identify the defect. 12 June 2009 © Rob Myers 2009 27
    28. Business-Value-Centric 12 June 2009 © Rob Myers 2009 28
    29. If Only… • …We could automate the tests without making them brittle… • …We could write tests without having to see the working product… • …We could do so without having to write in a programming language… 12 June 2009 © Rob Myers 2009 29
    30. Inconceivable! “You keep using that word. I do not think it means what you think it means…” -- Inigo Montoya The Princess Bride (1987) 12 June 2009 © Rob Myers 2009 30
    31. INTRO TO FIT Examples of Examples 12 June 2009 © Rob Myers 2009 31
    32. Fit: Framework for Integrated Tests Invented by Ward Cunningham 12 June 2009 © Rob Myers 2009 32
    33. Fit is Unique • We can test any “layer,” thus expanding our creative reach. • We usually avoid the UI layer. • Fit is simple. It does very little, and you can do so much with it. 12 June 2009 © Rob Myers 2009 33
    34. The First Martian Hotel 12 June 2009 © Rob Myers 2009 34
    35. The “Column” Fixture • For functions and calculations. • Can be used to “Arrange” the test. 12 June 2009 © Rob Myers 2009 35
    36. Fit Output 12 June 2009 © Rob Myers 2009 36 _s
    37. What Fit does to Your Tests Your Fit test (HTML, Excel) Fit report (HTML) Fit Fit Fixture (Test Code) System Under Test 12 June 2009 © Rob Myers 2009 37
    38. ColumnFixture Code using System; using fit; public class StayPointsStatus : ColumnFixture { public int recentAccruals; public int recentStays; public string Status() { Guests.StayPointsStatus status = Guests.StayPointsStatus.FromRecentActivity( recentAccruals, recentStays); return status.ToString(); } } 12 June 2009 © Rob Myers 2009 38
    39. The “Row” Fixture • For asserting state. (No input.) • For lists. • Shows missing rows as failures. • Shows extra rows as failures. • Declarative. 12 June 2009 © Rob Myers 2009 39
    40. RowFixture Code – Part 1 public class OccupiedRooms : RowFixture { public override Type GetTargetClass() { return typeof(OccupiedRoomRecord); } public override object[] Query() { List<Room> rooms = Hotel.Instance().occupiedRooms(); object[] answer = new object[rooms.Count]; int answerIndex = 0; foreach (Room room in rooms) { answer[answerIndex++] = new OccupiedRoomRecord(room); } return answer; } } 12 June 2009 © Rob Myers 2009 40
    41. RowFixture Code – Part 2 public class OccupiedRoomRecord { private Room theRoom; public OccupiedRoomRecord(Room room) { theRoom = room; } public int RoomNumber() { return theRoom.RoomNumber(); } public string RegisteredOccupantName() { return theRoom.Occupant; } } 12 June 2009 © Rob Myers 2009 41
    42. The “Action” Fixture • For a sequence of events. • For simple scripting. • Imperative. 12 June 2009 © Rob Myers 2009 42
    43. ActionFixture Code public class Registration : Fixture { private Room room; public int roomsAvailable() { return GetHotel().WhateverIsRequired...(...); } public int roomNumber() { if (room == null) return -1; return room.RoomNumber(); } public void selectRoom() { ... } public void register() { ... } public void smoking(String smoking) { ... } } 12 June 2009 © Rob Myers 2009 43
    44. Error Conditions 12 June 2009 © Rob Myers 2009 44
    45. Tests Can Have Many Tables 12 June 2009 © Rob Myers 2009 45
    46. The Agile Team Using Fit for ATDD 1. Testers and other teammates enter tests into Fit pages. 2. Developers develop Fit fixtures for the tables. 3. The team collaborates on the shape of the tables and Fit fixtures until they express what needs to be accomplished. 4. They run the tests and watch them fail cleanly (RED, not YELLOW). 5. Developers develop until tests pass. 12 June 2009 © Rob Myers 2009 46
    47. FITLIBRARY And Other Improvements 12 June 2009 © Rob Myers 2009 47
    48. Sample Test Folder Structure All Tests Really Slow Acceptance Tests Tests Prior Current Iterations Iteration Iteration 1 Iteration 2 12 June 2009 © Rob Myers 2009 48
    49. setup.html Files setup.htm All Tests setup.htm Really Slow Acceptance Tests Tests Prior Current Iterations Iteration setup.htm Iteration 1 Iteration 2 aTest.htm 12 June 2009 © Rob Myers 2009 49
    50. The “Set Up” Fixture 12 June 2009 © Rob Myers 2009 50
    51. SetUpFixture Code using fitlibrary; public class CreateRooms : SetUpFixture { public void RoomNumberBedsSmokingAllowed( int roomNumber, string beds, string smokingAllowed) { Room room = new Room(roomNumber, Registration.convertBeds(beds), Registration.convertSmoking(smokingAllowed)); hotel().addRoom(room); } } 12 June 2009 © Rob Myers 2009 51
    52. The “Do” Fixture 12 June 2009 © Rob Myers 2009 52
    53. Same Test, Additional Activities 12 June 2009 © Rob Myers 2009 53
    54. DoFixture Code using fitlibrary; public class DoRegistration : DoFixture { private Room room; public void SelectRoom() { room = hotel().nextAvailableRoom(); } public int RoomNumber() { return room.RoomNumber(); } public void RegisterPayment( string name, string paymentStatus) { hotel().register(room, name, paymentStatus); } } 12 June 2009 © Rob Myers 2009 54
    55. REFACTORING CLEAN CODE Providing Business Value Via Just-In-Time Design 12 June 2009 © Rob Myers 2009 55
    56. Do I Need Tests To Refactor? 12 June 2009 © Rob Myers 2009 56
    57. 12 June 2009 © Rob Myers 2009 57
    58. The “Open-Closed Principle” “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.” Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988, p. 23 http://en.wikipedia.org/wiki/Open/closed_principle 12 June 2009 © Rob Myers 2009 58
    59. …so, “refactoring to open-closed” would mean changing code so you can add behavior without changing code… 12 June 2009 © Rob Myers 2009 59
    60. Driving Directions…on Mars 12 June 2009 © Rob Myers 2009 60
    61. Starting Point Map + Refresh() + Zoom() + Move() 12 June 2009 © Rob Myers 2009 61
    62. Collect Related behavior Map + Refresh() + Zoom() + Move() Earth 12 June 2009 © Rob Myers 2009 62
    63. Provide An Abstraction Map Planet + Refresh() + Zoom() + Move() Earth 12 June 2009 © Rob Myers 2009 63
    64. Use the Abstraction Map Planet + Refresh() + Zoom() + Move() Earth 12 June 2009 © Rob Myers 2009 64
    65. Separate Building from Using Map Planet + Refresh() + Zoom() + Move() PlanetFactory Earth + Planet URHere() creates 12 June 2009 © Rob Myers 2009 65
    66. Add the New Behavior • Use TDD to create the new variation within the abstraction. • Use TDD to alter the factory to build the new variation when appropriate. • Integrate and celebrate! 12 June 2009 © Rob Myers 2009 66
    67. The New Design Map Planet + Refresh() + Zoom() + Move() PlanetFactory Earth Mars + Planet URHere() creates 12 June 2009 © Rob Myers 2009 67
    68. 12 June 2009 © Rob Myers 2009 68
    69. SUPPORTING DOCUMENTATION Survey results indicating improvement via Agile methods 12 June 2009 © Rob Myers 2009 69
    70. What others are seeing
    71. VersionOne Survey Results (2008) Survey asked people: Please try to estimate SPECIFIC IMPROVEMENTS you have actually realized from implementing Agile practices. Improvement Noted >10% >=25% improvement improvement Increased productivity 89% 56% Reduced software defects 84% 56% Accelerated time-to-market 83% 54% Reduced cost 65% 30% Source: VersionOne 2008 State of Agile Development Survey NOTE: All 2008 data is within 2% of 2007 data implying these numbers are not one-time anomolies Biggest causes of agile project failure: Company philosophy or culture could not be overcome – 23% Lack of experience with agile – 21%
    72. Agile is a Proven Approach Some Agile Companies (there are MANY more)
    73. BIBLIOGRAPHY 12 June 2009 © Rob Myers 2009 73
    74. Refactoring – Martin Fowler Addison-Wesley July 8, 1999 ISBN-10: 0201485672 ISBN-13: 978-0201485677 12 June 2009 © Rob Myers 2009 74
    75. Fit for Developing Software – Rick Mugridge Prentice Hall July 9, 2005 ISBN-10: 0321269349 ISBN-13: 978-0321269348 12 June 2009 © Rob Myers 2009 75
    76. The Art of Agile Development – James Shore & Shane Warden O'Reilly Media, Inc. October 26, 2007 ISBN-10: 0596527675 ISBN-13: 978-0596527679 12 June 2009 © Rob Myers 2009 76
    SlideShare Zeitgeist 2009

    + Rob MyersRob Myers Nominate

    custom

    242 views, 1 favs, 0 embeds more stats

    Technical debt can crush a project, whether or not more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 242
      • 242 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 1
    • Downloads 0
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories

    Tags

    -->
    Search
    RSS Feed
    What's new?

    © 2009 SlideShare Inc. All Rights Reserved