SlideShare a Scribd company logo
1 of 54
Download to read offline
Pragmatic, Not
        Dogmatic TDD:
Rethinking How We Test
        Joseph W. Yoder
        The Refactory, Inc.

   Rebecca Wirfs-Brock
    Wirfs-Brock Associates


 Copyright 2012 Joseph Yoder, Rebecca Wirfs-Brock,
   The Refactory, Inc. and Wirfs-Brock Associates
Introducing Joseph
Founder and Architect, The Refactory, Inc.
Pattern enthusiast, author and Hillside
   Board President
Author of the Big Ball of Mud Pattern
Adaptive systems expert (programs
   adaptive software, consults on adaptive
   architectures, author of adaptive
   architecture patterns, metatdata maven,
   website: adaptiveobjectmodel.com)
Agile enthusiast and practitioner
Business owner (leads a world class
   development company)
Consults and trains top companies on
   design, refactoring, pragmatic testing
Amateur photographer, motorcycle
   enthusiast, enjoys dancing samba!!!
Introducing Rebecca
President, Wirfs-Brock Associates
Agile enthusiast (involved with experience
   reports since 1st agile conference, board
   president Agile Open Northwest, past
   Agile Alliance Board member)
Pattern enthusiast, author, and Hillside
   Board Treasurer
Old design geek (author of two object
   design books, inventor of Responsibility-
   Driven Design, advocate of CRC cards,
   hot spot cards, & other low-tech design
   tools, IEEE Software design columnist)
Consults and trains top companies on agile
   architecture, responsibility-driven design,
   enterprise app design, agile use cases,
   design storytelling, pragmatic testing
Runs marathons!!!
Some Agile Myths
  Simple solutions are always best.
  We can easily adapt to changing
  requirements (new requirements).
  Because I’m following TDD, I can
  reliably change the system fast!!!
  TDD will ensure good Design.
      “www.agilemyths.com”
First
   Classic Test-Driven Development
Start                                                    Write
                                            test fails
        Re(Write)             Check if                   production
        a test                test fails                 code




                                                                      1 or more
                                                                       tests fail
                  test succeeds
                                           all tests
                      Clean up code         succeed        Check
                                                          all tests
                        (Refactor)                        succeed



          Ship             Ready to
          it!!!            Release?
                                                             Short Cycles
TDD Promises
1 Tests help you build the right thing
2 Tests guide development
3 Tests keep you focused
4 Tests allow you to change
  code safely and quickly
5 Tests ensure what you build works
6 You will end up with quality code
7 You will end up with a good design
Question: Do tests help you
build the right things?
Common Misperceptions
 Tests verify program correctness
     3.1415926535…


 Tests enable and encourage
 well-designed code
Understanding
        Tests
Test Target → the thing
T   we are trying to test.

    Action → changes environment
    or the Test Target.

    Assertion → compares expected
    vs observable outcome of the
    action on the Test Target.
Test → a sequence
of at least one action
    and one assertion

          T       T’
Good Test Outline
1. Set up
2. Declare the expected results
3. Exercise the test
4. Get the actual results
5. Assert that the actual results
   match the expected results
6. Teardown
Pragmatic Testing Questions
 What is important to test?
 Who should write them?
 Who runs them?
 When are they run?
 How are they run?
What to Test
Significant scenarios of use, not
isolated methods.
The difficult parts: Complex interactions,
intricate algorithms, tricky business logic
Required system qualities
    Performance, scalability,
     throughput, security...
How services respond to normal
and exceptional invocations.
What Not to Test
 Tests should add value,
 not just be an exercise.
 Do not test:
    setters and getters
      (unless they have side effects or are very complex)
    every boundary condition; only test
     those with significant business value
    every exception; only those likely to occur
     or that will cause catastrophic problems.
Different Tests Can Overlap…
                  Smoke
                   Tests   Quality
                           Scenarios
    Integration
       Tests
                                Acceptance Tests


                  Unit
                  Tests


Common to only focus on Unit Tests in TDD!!!
We believe TDD is more than just Unit Tests
Question: Do tests help you
build the right things?

Answer: Yes. But …
Question: Do tests guide
development and keep you
focused?
Two Faces of Testing
Defining tests            But you may
helps limit               be missing
scope and                 the bigger
increases focus           picture…
Tests force you           Might need to
to implement              consider how
functionality             current
instead of                functionality
jumping around            affects the
and tweaking              rest of the
stuff                     system
Thinking Fast vs. Slow
  Fast thinking:
  decisions based on
  intuition, biases,
  ingrained patterns,
  and emotions

  Slow thinking:
  Reasoning, logical
  thinking
Take Time For Both
  Slow thinking
     Pairing and discussion options
      are why you want to implement
      something a certain way
     Sketching, noodling, design spikes

  Fast thinking
     Fast turns of coding, testing and
      quick fixes… (Red/Green)
Question: Do tests guide
development and keep
you focused?

Answer: Yes…but…
Ten Tenets of Testing
1. Test single complete scenarios
2. Do not create dependencies between tests
3. Only verify a single thing in each assertion
4. Respect class encapsulation
5. Test limit values and boundaries
6. Test expected exceptional scenarios
7. Test interactions with other objects
8. When you find a bug, write a test to show it
9. Do not duplicate application logic in tests
10. Keep your test code clean
Question: Do I always have
to write tests first?
You are not
  doing TDD!         Common Belief
You must create
                        You are not
 your tests first!      practicing TDD
                        correctly
                        unless you
                        write tests
                        first, before
                        writing any
                        code that is
                        tested.
Is it OK to write tests after
you write production code?
  Is this cheating?
  Does this result in bad code?
  Does it result in a bad design?
  Does it reinforce “slacker”
  tendencies to not write tests?
Common Practice
     Tests don’t always get written first.
Start
                                                   Write
                                        test fails
        Re(Write)           Check if               production
        a test              test fails             code




                                                                1 or more
                                                                 tests fail
                  test succeeds
                                      all tests
                      Clean up code    succeed       Check
                                                    all tests
                        (Refactor)                  succeed



          Ship             Ready to
          it!!!            Release?
A Pragmatic Testing Cycle
 Code is only checked in with Valid Tests that verify
 that code works as expected (validate tests too)!!!

Write some                                      Check if
                       Re(write)
production                                      test fails
                       a test
code

                Clean up code
                  (Refactor)           1 or more
                                       tests fail Check
       all tests succeed                        all tests
                                                succeed
       Ship          Ready to
       it!!!         Release?
Pragmatic Testing Cycle
Alternate between writing
  test code and production
  in small steps.
Use feedback from tests
 to verify code (integrate often).
Don’t worry whether the chicken or
 the egg comes first. Sometimes
 development guides testing.
Do what yields the most value!
Question: Do I always have
to write tests first?

Answer: No, as long as tests are
checked in with production code!
Question: Do tests allow
you to change code safely
and quickly?
Test-Driven   Refactoring
Development
Common Wisdom
Work refactoring into your daily routine…

 “In almost all cases, I’m
 opposed to setting aside time
 for refactoring. In my view
 refactoring is not an activity
 you set aside time to do.
 Refactoring is something
 you do all the time in little
 bursts.” — Martin Fowler
Two Refactoring Types*
 Floss Refactorings—frequent,
 small changes, intermingled
 with other programming
 (daily health)

 Root canal refactorings —
 infrequent, protracted
 refactoring, during which
 programmers do nothing
 else (major repair)
* Emerson Murphy-Hill and Andrew Black in
 “Refactoring Tools: Fitness for Purpose”
http://web.cecs.pdx.edu/~black/publications/IEEESoftwareRefact.pdf
What if the Tests are an
Obstacle to Refactoring?
The design of test code
needs to evolve, just like
   production code!
Sometimes it is easier to throw
away tests, change the design
of your production code, and
then write new tests.
Question: Do tests allow
you to change code safely
and quickly?

Answer: Yes and no.
Question: Do tests help with
quality code and good design?
Agile Design Values
  Core values:
     Design Simplicity
     Communication
     Teamwork
     Trust
     Satisfying stakeholder needs
  Keep learning
  Lots of Testing!!!
Classic Test-Driven
Development Rhythm
                 User story-by-story:
                     Write the simplest test
                     Run the test and fail
                     Write the simplest code
                      that will pass the test
                     Run the test and pass
                 Repeat until a “story”
                 is tested and
                 implemented
                 “Design happens
                  between the
                  keystrokes”
Another View of
Test-Driven Development
  Requirements             Architecture
   Envisioning             Envisioning           Conceptual Modeling
 (days/weeks/...)        (days/weeks/…)
                    Iteration 0: Envisioning



           Iteration Modeling
                 (hours)
                                       a little bit of modeling
             Model Storming             then a lot of coding
               (minutes)

                 Fast
              TDD(hours)
        Iteration n: Development
Spike Solutions
If some technical difficulty
  threatens to hold up the
  system's development,
Or you are not sure how to
 solve a particular problem…
  “Put a pair of developers on the
    problem for a week or two to
    reduce the potential risk”
Other Techniques for
Improving Quality
Steve McConnell
http://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/
Combine and Conquer
 The average is 40% for
    any one technique…
 No one approach is adequate
 Combining techniques gives
    you much higher quality
Question: Do tests help with
quality code and good design?

Answer: They can but …
you need more than tests.
Pragmatic Test-Driven
 Development (core process)
 Tests written & must pass before checking in production code

Write some                                    Check if
                      Re(write)
production                                    test fails
                      a test
code

               Clean up code
                 (Refactor)          1 or more
                                     tests fail Check
       all tests succeed                      all tests
                                              succeed
      Ship          Ready to
      it!!!         Release?                     Good Tests
TDD Challenges
1. Unit Tests aren’t enough…
   should they be the main focus?
2. It is hard to know the “right” tests
3. Deception that incrementally writing
   tests inductively proves software works…
   probably more deductive and example driven…
4. Tests can constrain code
   evolution and refactoring
Dogmatic
Synonyms: bullheaded,
dictative, doctrinaire,
fanatical, intolerant

Antonyms: amenable,
flexible, manageable


                          Pragmatic
                          Synonyms: common,
                          commonsense, logical,
                          practical, rational,
                          realistic, sensible

                          Antonyms: idealistic, unrealistic
Be Pragmatic…
Use tests to enhance your current practice!
Ask how best to validate that your
software meets its requirements.
Develop the optimum set of tests to keep
your system working, not only Unit Tests!
Make time for slow thinking too.
Keep It Focused
       Keep It Fresh
Expand your Horizons




       …Be Practical
Resources
Agile Myths: agilemyths.com
The Refactory: www.refactory.com
Joe’s website: joeyoder.com
Wirfs-Brock Associates: www.wirfs-brock.com
Our Pragmatic TDD Course:
   refactory.com/training/test-driven-development
   wirfs-brock.com/pragmatictestdrivendevelopment.html
Introducing Pragmatic TDD:
   wirfs-brock.com/blog/2011/09/23/what-is-pragmatic-
    testing-all-about/
   http://adaptiveobjectmodel.com/2012/01/what-is-
    pragmatic-tdd/

More Related Content

What's hot

Agile and ATDD the perfect couple
Agile and ATDD the perfect coupleAgile and ATDD the perfect couple
Agile and ATDD the perfect couple
Stephen Tucker
 
Using tests and mocks to drive the design of software
Using tests and mocks to drive the design of softwareUsing tests and mocks to drive the design of software
Using tests and mocks to drive the design of software
Attila Magyar
 
TechDays 2013 Juhani Lind: Acceptance Test Driven Development With VS 2012
TechDays 2013 Juhani Lind: Acceptance Test Driven Development With VS 2012TechDays 2013 Juhani Lind: Acceptance Test Driven Development With VS 2012
TechDays 2013 Juhani Lind: Acceptance Test Driven Development With VS 2012
Tieturi Oy
 

What's hot (16)

Agile and ATDD the perfect couple
Agile and ATDD the perfect coupleAgile and ATDD the perfect couple
Agile and ATDD the perfect couple
 
Michael Bolton - Two futures of software testing - Sept 2010
Michael Bolton - Two futures of software testing - Sept 2010Michael Bolton - Two futures of software testing - Sept 2010
Michael Bolton - Two futures of software testing - Sept 2010
 
Agile Testing Overview
Agile Testing OverviewAgile Testing Overview
Agile Testing Overview
 
TDD That Was Easy!
TDD   That Was Easy!TDD   That Was Easy!
TDD That Was Easy!
 
Using tests and mocks to drive the design of software
Using tests and mocks to drive the design of softwareUsing tests and mocks to drive the design of software
Using tests and mocks to drive the design of software
 
Real developers-dont-need-unit-tests
Real developers-dont-need-unit-testsReal developers-dont-need-unit-tests
Real developers-dont-need-unit-tests
 
Will The Test Leaders Stand Up?
Will The Test Leaders Stand Up?Will The Test Leaders Stand Up?
Will The Test Leaders Stand Up?
 
The Pursuit of Quality - Chasing Tornadoes or Just Hot Air?
The Pursuit of Quality - Chasing Tornadoes or Just Hot Air?The Pursuit of Quality - Chasing Tornadoes or Just Hot Air?
The Pursuit of Quality - Chasing Tornadoes or Just Hot Air?
 
The Design Process - FRC
The Design Process - FRCThe Design Process - FRC
The Design Process - FRC
 
Being a professional software tester
Being a professional software testerBeing a professional software tester
Being a professional software tester
 
Test Drive Development
Test Drive DevelopmentTest Drive Development
Test Drive Development
 
Scrum is not enough - being a successful agile engineer
Scrum is not enough - being a successful agile engineerScrum is not enough - being a successful agile engineer
Scrum is not enough - being a successful agile engineer
 
TEA Presentation V 0.3
TEA Presentation V 0.3TEA Presentation V 0.3
TEA Presentation V 0.3
 
Rethinking the Role of Testers
Rethinking the Role of TestersRethinking the Role of Testers
Rethinking the Role of Testers
 
Don't let your tests slow you down
Don't let your tests slow you downDon't let your tests slow you down
Don't let your tests slow you down
 
TechDays 2013 Juhani Lind: Acceptance Test Driven Development With VS 2012
TechDays 2013 Juhani Lind: Acceptance Test Driven Development With VS 2012TechDays 2013 Juhani Lind: Acceptance Test Driven Development With VS 2012
TechDays 2013 Juhani Lind: Acceptance Test Driven Development With VS 2012
 

Similar to Pragmatic Not Dogmatic TDD Agile2012 by Joseph Yoder and Rebecca Wirfs-Brock

Test-Driven Development Reference Card
Test-Driven Development Reference CardTest-Driven Development Reference Card
Test-Driven Development Reference Card
Seapine Software
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
bhochhi
 

Similar to Pragmatic Not Dogmatic TDD Agile2012 by Joseph Yoder and Rebecca Wirfs-Brock (20)

Test-Driven Development Reference Card
Test-Driven Development Reference CardTest-Driven Development Reference Card
Test-Driven Development Reference Card
 
Unit Testing, TDD and the Walking Skeleton
Unit Testing, TDD and the Walking SkeletonUnit Testing, TDD and the Walking Skeleton
Unit Testing, TDD and the Walking Skeleton
 
TDD refresher
TDD refresherTDD refresher
TDD refresher
 
JavaScript Unit Testing
JavaScript Unit TestingJavaScript Unit Testing
JavaScript Unit Testing
 
TDD talk
TDD talkTDD talk
TDD talk
 
An Introduction to Test Driven Development
An Introduction to Test Driven Development An Introduction to Test Driven Development
An Introduction to Test Driven Development
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
 
Agile Testing, Uncertainty, Risk, and Why It All Works
Agile Testing, Uncertainty, Risk, and Why It All WorksAgile Testing, Uncertainty, Risk, and Why It All Works
Agile Testing, Uncertainty, Risk, and Why It All Works
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
 
iOS Test-Driven Development
iOS Test-Driven DevelopmentiOS Test-Driven Development
iOS Test-Driven Development
 
Let's test!
Let's test!Let's test!
Let's test!
 
Unit Testing and TDD 2017
Unit Testing and TDD 2017Unit Testing and TDD 2017
Unit Testing and TDD 2017
 
Fantastic Tests - The Crimes of Bad Test Design
Fantastic Tests - The Crimes of Bad Test DesignFantastic Tests - The Crimes of Bad Test Design
Fantastic Tests - The Crimes of Bad Test Design
 
Things Could Get Worse: Ideas About Regression Testing
Things Could Get Worse: Ideas About Regression TestingThings Could Get Worse: Ideas About Regression Testing
Things Could Get Worse: Ideas About Regression Testing
 
Getting started with Test Driven Development - Ferdous Mahmud Shaon
Getting started with Test Driven Development - Ferdous Mahmud ShaonGetting started with Test Driven Development - Ferdous Mahmud Shaon
Getting started with Test Driven Development - Ferdous Mahmud Shaon
 
Tdd
TddTdd
Tdd
 
TDD Best Practices
TDD Best PracticesTDD Best Practices
TDD Best Practices
 
Getting started with Test Driven Development
Getting started with Test Driven DevelopmentGetting started with Test Driven Development
Getting started with Test Driven Development
 
Intro to TDD
Intro to TDDIntro to TDD
Intro to TDD
 
Test-Driven Development
 Test-Driven Development  Test-Driven Development
Test-Driven Development
 

Recently uploaded

Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
FIDO Alliance
 
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
panagenda
 
Microsoft BitLocker Bypass Attack Method.pdf
Microsoft BitLocker Bypass Attack Method.pdfMicrosoft BitLocker Bypass Attack Method.pdf
Microsoft BitLocker Bypass Attack Method.pdf
Overkill Security
 
CORS (Kitworks Team Study 양다윗 발표자료 240510)
CORS (Kitworks Team Study 양다윗 발표자료 240510)CORS (Kitworks Team Study 양다윗 발표자료 240510)
CORS (Kitworks Team Study 양다윗 발표자료 240510)
Wonjun Hwang
 

Recently uploaded (20)

Continuing Bonds Through AI: A Hermeneutic Reflection on Thanabots
Continuing Bonds Through AI: A Hermeneutic Reflection on ThanabotsContinuing Bonds Through AI: A Hermeneutic Reflection on Thanabots
Continuing Bonds Through AI: A Hermeneutic Reflection on Thanabots
 
How we scaled to 80K users by doing nothing!.pdf
How we scaled to 80K users by doing nothing!.pdfHow we scaled to 80K users by doing nothing!.pdf
How we scaled to 80K users by doing nothing!.pdf
 
Top 10 CodeIgniter Development Companies
Top 10 CodeIgniter Development CompaniesTop 10 CodeIgniter Development Companies
Top 10 CodeIgniter Development Companies
 
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
 
(Explainable) Data-Centric AI: what are you explaininhg, and to whom?
(Explainable) Data-Centric AI: what are you explaininhg, and to whom?(Explainable) Data-Centric AI: what are you explaininhg, and to whom?
(Explainable) Data-Centric AI: what are you explaininhg, and to whom?
 
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
 
Frisco Automating Purchase Orders with MuleSoft IDP- May 10th, 2024.pptx.pdf
Frisco Automating Purchase Orders with MuleSoft IDP- May 10th, 2024.pptx.pdfFrisco Automating Purchase Orders with MuleSoft IDP- May 10th, 2024.pptx.pdf
Frisco Automating Purchase Orders with MuleSoft IDP- May 10th, 2024.pptx.pdf
 
Navigating the Large Language Model choices_Ravi Daparthi
Navigating the Large Language Model choices_Ravi DaparthiNavigating the Large Language Model choices_Ravi Daparthi
Navigating the Large Language Model choices_Ravi Daparthi
 
Design Guidelines for Passkeys 2024.pptx
Design Guidelines for Passkeys 2024.pptxDesign Guidelines for Passkeys 2024.pptx
Design Guidelines for Passkeys 2024.pptx
 
Vector Search @ sw2con for slideshare.pptx
Vector Search @ sw2con for slideshare.pptxVector Search @ sw2con for slideshare.pptx
Vector Search @ sw2con for slideshare.pptx
 
ADP Passwordless Journey Case Study.pptx
ADP Passwordless Journey Case Study.pptxADP Passwordless Journey Case Study.pptx
ADP Passwordless Journey Case Study.pptx
 
Microsoft BitLocker Bypass Attack Method.pdf
Microsoft BitLocker Bypass Attack Method.pdfMicrosoft BitLocker Bypass Attack Method.pdf
Microsoft BitLocker Bypass Attack Method.pdf
 
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
 
WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024
 
How to Check CNIC Information Online with Pakdata cf
How to Check CNIC Information Online with Pakdata cfHow to Check CNIC Information Online with Pakdata cf
How to Check CNIC Information Online with Pakdata cf
 
CORS (Kitworks Team Study 양다윗 발표자료 240510)
CORS (Kitworks Team Study 양다윗 발표자료 240510)CORS (Kitworks Team Study 양다윗 발표자료 240510)
CORS (Kitworks Team Study 양다윗 발표자료 240510)
 
2024 May Patch Tuesday
2024 May Patch Tuesday2024 May Patch Tuesday
2024 May Patch Tuesday
 
How to Check GPS Location with a Live Tracker in Pakistan
How to Check GPS Location with a Live Tracker in PakistanHow to Check GPS Location with a Live Tracker in Pakistan
How to Check GPS Location with a Live Tracker in Pakistan
 
AI mind or machine power point presentation
AI mind or machine power point presentationAI mind or machine power point presentation
AI mind or machine power point presentation
 
The Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and InsightThe Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and Insight
 

Pragmatic Not Dogmatic TDD Agile2012 by Joseph Yoder and Rebecca Wirfs-Brock

  • 1. Pragmatic, Not Dogmatic TDD: Rethinking How We Test Joseph W. Yoder The Refactory, Inc. Rebecca Wirfs-Brock Wirfs-Brock Associates Copyright 2012 Joseph Yoder, Rebecca Wirfs-Brock, The Refactory, Inc. and Wirfs-Brock Associates
  • 2. Introducing Joseph Founder and Architect, The Refactory, Inc. Pattern enthusiast, author and Hillside Board President Author of the Big Ball of Mud Pattern Adaptive systems expert (programs adaptive software, consults on adaptive architectures, author of adaptive architecture patterns, metatdata maven, website: adaptiveobjectmodel.com) Agile enthusiast and practitioner Business owner (leads a world class development company) Consults and trains top companies on design, refactoring, pragmatic testing Amateur photographer, motorcycle enthusiast, enjoys dancing samba!!!
  • 3. Introducing Rebecca President, Wirfs-Brock Associates Agile enthusiast (involved with experience reports since 1st agile conference, board president Agile Open Northwest, past Agile Alliance Board member) Pattern enthusiast, author, and Hillside Board Treasurer Old design geek (author of two object design books, inventor of Responsibility- Driven Design, advocate of CRC cards, hot spot cards, & other low-tech design tools, IEEE Software design columnist) Consults and trains top companies on agile architecture, responsibility-driven design, enterprise app design, agile use cases, design storytelling, pragmatic testing Runs marathons!!!
  • 4. Some Agile Myths Simple solutions are always best. We can easily adapt to changing requirements (new requirements). Because I’m following TDD, I can reliably change the system fast!!! TDD will ensure good Design. “www.agilemyths.com”
  • 5.
  • 6. First Classic Test-Driven Development Start Write test fails Re(Write) Check if production a test test fails code 1 or more tests fail test succeeds all tests Clean up code succeed Check all tests (Refactor) succeed Ship Ready to it!!! Release? Short Cycles
  • 7. TDD Promises 1 Tests help you build the right thing 2 Tests guide development 3 Tests keep you focused 4 Tests allow you to change code safely and quickly 5 Tests ensure what you build works 6 You will end up with quality code 7 You will end up with a good design
  • 8.
  • 9. Question: Do tests help you build the right things?
  • 10. Common Misperceptions Tests verify program correctness  3.1415926535… Tests enable and encourage well-designed code
  • 11. Understanding Tests
  • 12. Test Target → the thing T we are trying to test. Action → changes environment or the Test Target. Assertion → compares expected vs observable outcome of the action on the Test Target.
  • 13. Test → a sequence of at least one action and one assertion T T’
  • 14. Good Test Outline 1. Set up 2. Declare the expected results 3. Exercise the test 4. Get the actual results 5. Assert that the actual results match the expected results 6. Teardown
  • 15. Pragmatic Testing Questions What is important to test? Who should write them? Who runs them? When are they run? How are they run?
  • 16. What to Test Significant scenarios of use, not isolated methods. The difficult parts: Complex interactions, intricate algorithms, tricky business logic Required system qualities  Performance, scalability, throughput, security... How services respond to normal and exceptional invocations.
  • 17. What Not to Test Tests should add value, not just be an exercise. Do not test:  setters and getters (unless they have side effects or are very complex)  every boundary condition; only test those with significant business value  every exception; only those likely to occur or that will cause catastrophic problems.
  • 18. Different Tests Can Overlap… Smoke Tests Quality Scenarios Integration Tests Acceptance Tests Unit Tests Common to only focus on Unit Tests in TDD!!! We believe TDD is more than just Unit Tests
  • 19. Question: Do tests help you build the right things? Answer: Yes. But …
  • 20. Question: Do tests guide development and keep you focused?
  • 21. Two Faces of Testing Defining tests But you may helps limit be missing scope and the bigger increases focus picture… Tests force you Might need to to implement consider how functionality current instead of functionality jumping around affects the and tweaking rest of the stuff system
  • 22. Thinking Fast vs. Slow Fast thinking: decisions based on intuition, biases, ingrained patterns, and emotions Slow thinking: Reasoning, logical thinking
  • 23. Take Time For Both Slow thinking  Pairing and discussion options are why you want to implement something a certain way  Sketching, noodling, design spikes Fast thinking  Fast turns of coding, testing and quick fixes… (Red/Green)
  • 24. Question: Do tests guide development and keep you focused? Answer: Yes…but…
  • 25. Ten Tenets of Testing 1. Test single complete scenarios 2. Do not create dependencies between tests 3. Only verify a single thing in each assertion 4. Respect class encapsulation 5. Test limit values and boundaries 6. Test expected exceptional scenarios 7. Test interactions with other objects 8. When you find a bug, write a test to show it 9. Do not duplicate application logic in tests 10. Keep your test code clean
  • 26. Question: Do I always have to write tests first?
  • 27. You are not doing TDD! Common Belief You must create You are not your tests first! practicing TDD correctly unless you write tests first, before writing any code that is tested.
  • 28. Is it OK to write tests after you write production code? Is this cheating? Does this result in bad code? Does it result in a bad design? Does it reinforce “slacker” tendencies to not write tests?
  • 29. Common Practice Tests don’t always get written first. Start Write test fails Re(Write) Check if production a test test fails code 1 or more tests fail test succeeds all tests Clean up code succeed Check all tests (Refactor) succeed Ship Ready to it!!! Release?
  • 30. A Pragmatic Testing Cycle Code is only checked in with Valid Tests that verify that code works as expected (validate tests too)!!! Write some Check if Re(write) production test fails a test code Clean up code (Refactor) 1 or more tests fail Check all tests succeed all tests succeed Ship Ready to it!!! Release?
  • 31. Pragmatic Testing Cycle Alternate between writing test code and production in small steps. Use feedback from tests to verify code (integrate often). Don’t worry whether the chicken or the egg comes first. Sometimes development guides testing. Do what yields the most value!
  • 32. Question: Do I always have to write tests first? Answer: No, as long as tests are checked in with production code!
  • 33. Question: Do tests allow you to change code safely and quickly?
  • 34. Test-Driven Refactoring Development
  • 35. Common Wisdom Work refactoring into your daily routine… “In almost all cases, I’m opposed to setting aside time for refactoring. In my view refactoring is not an activity you set aside time to do. Refactoring is something you do all the time in little bursts.” — Martin Fowler
  • 36. Two Refactoring Types* Floss Refactorings—frequent, small changes, intermingled with other programming (daily health) Root canal refactorings — infrequent, protracted refactoring, during which programmers do nothing else (major repair) * Emerson Murphy-Hill and Andrew Black in “Refactoring Tools: Fitness for Purpose” http://web.cecs.pdx.edu/~black/publications/IEEESoftwareRefact.pdf
  • 37. What if the Tests are an Obstacle to Refactoring?
  • 38. The design of test code needs to evolve, just like production code!
  • 39. Sometimes it is easier to throw away tests, change the design of your production code, and then write new tests.
  • 40. Question: Do tests allow you to change code safely and quickly? Answer: Yes and no.
  • 41. Question: Do tests help with quality code and good design?
  • 42. Agile Design Values Core values:  Design Simplicity  Communication  Teamwork  Trust  Satisfying stakeholder needs Keep learning Lots of Testing!!!
  • 43. Classic Test-Driven Development Rhythm User story-by-story:  Write the simplest test  Run the test and fail  Write the simplest code that will pass the test  Run the test and pass Repeat until a “story” is tested and implemented “Design happens between the keystrokes”
  • 44. Another View of Test-Driven Development Requirements Architecture Envisioning Envisioning Conceptual Modeling (days/weeks/...) (days/weeks/…) Iteration 0: Envisioning Iteration Modeling (hours) a little bit of modeling Model Storming then a lot of coding (minutes) Fast TDD(hours) Iteration n: Development
  • 45. Spike Solutions If some technical difficulty threatens to hold up the system's development, Or you are not sure how to solve a particular problem… “Put a pair of developers on the problem for a week or two to reduce the potential risk”
  • 46. Other Techniques for Improving Quality Steve McConnell http://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/
  • 47. Combine and Conquer The average is 40% for any one technique… No one approach is adequate Combining techniques gives you much higher quality
  • 48. Question: Do tests help with quality code and good design? Answer: They can but … you need more than tests.
  • 49. Pragmatic Test-Driven Development (core process) Tests written & must pass before checking in production code Write some Check if Re(write) production test fails a test code Clean up code (Refactor) 1 or more tests fail Check all tests succeed all tests succeed Ship Ready to it!!! Release? Good Tests
  • 50. TDD Challenges 1. Unit Tests aren’t enough… should they be the main focus? 2. It is hard to know the “right” tests 3. Deception that incrementally writing tests inductively proves software works… probably more deductive and example driven… 4. Tests can constrain code evolution and refactoring
  • 51. Dogmatic Synonyms: bullheaded, dictative, doctrinaire, fanatical, intolerant Antonyms: amenable, flexible, manageable Pragmatic Synonyms: common, commonsense, logical, practical, rational, realistic, sensible Antonyms: idealistic, unrealistic
  • 52. Be Pragmatic… Use tests to enhance your current practice! Ask how best to validate that your software meets its requirements. Develop the optimum set of tests to keep your system working, not only Unit Tests! Make time for slow thinking too.
  • 53. Keep It Focused Keep It Fresh Expand your Horizons …Be Practical
  • 54. Resources Agile Myths: agilemyths.com The Refactory: www.refactory.com Joe’s website: joeyoder.com Wirfs-Brock Associates: www.wirfs-brock.com Our Pragmatic TDD Course:  refactory.com/training/test-driven-development  wirfs-brock.com/pragmatictestdrivendevelopment.html Introducing Pragmatic TDD:  wirfs-brock.com/blog/2011/09/23/what-is-pragmatic- testing-all-about/  http://adaptiveobjectmodel.com/2012/01/what-is- pragmatic-tdd/