• Save
The ten commandments of TDD
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

The ten commandments of TDD

on

  • 1,034 views

 

Statistics

Views

Total Views
1,034
Views on SlideShare
1,030
Embed Views
4

Actions

Likes
2
Downloads
0
Comments
0

2 Embeds 4

http://a0.twimg.com 2
http://paper.li 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

The ten commandments of TDD Presentation Transcript

  • 1. The Ten Commandments of TDD Hernán Wilkinson Agile 2011
  • 2.
    • What is TDD?
  • 3.
    • This is NOT TDD, this is how you do it!
    So… what is the ESENCE of TDD
  • 4.
    • TDD is not about testing only
    • It is more than that…
  • 5.
    • TDD is about doing incremental problem solving guided by concrete examples
    • We are use to incremental development (cycles/iteration), but not incremental design/programming
  • 6.
    • TDD brings testing to development cycle
    Analisys Design Program. Testing
  • 7.
    • TDD brings testing to development cycle
    Analisys Design Program. Testing
  • 8.
    • TDD brings testing to development cycle
    • Tests are explicit, not implicit anymore
    • Tests run automatically, not because the a person test
    • Tests bring requirements to live!
  • 9.
    • TDD SINCERIZA programmers about testing
  • 10.
    • A programmer that is not a good tester is not a good programmer
    • Good Programmer = Good Tester
    =
  • 11.
    • TDD is a cultural change… a big one
  • 12.
    • The Commandments
    • Management ones
    • Technical one
      • About testing
      • About design
    • (Sadly, they are more than ten…)
  • 13.
    • The Management Commandments
  • 14.
    • You shall not expect your developers do TDD because it is God, I mean Good 
  • 15.
    • You shall not expect your developers do TDD because it is God, I mean Good 
    • It is a Cultural Change!
    • Cultural changes do not happen by themselves
    • As manager, you have to provide the environment for the change and support it
    • … and yes sometimes you have to be tuff, it is part of being a leader
    • It is great start doing Pair Programming!
  • 16.
    • You shall provide time to do TDD
  • 17.
    • You shall provide time to do TDD
    • YES!! Doing TDD TAKES TIME!!! and more at the beginning… It is a cultural change!
    • BUT… the time you “invest” doing TDD gets pay in the mid-term
    • Finding a bug running the tests during a regression has no price!… for the rest you have mastercard
  • 18.
    • You shall not send mixed messages stopping TDD when time looks not enough
  • 19.
    • You shall not send mixed messages stopping TDD when time looks not enough
    • The problem is the PLAN… it is a PLAN for God sake!
    • If you HAVE TO do it, provide a reasonable explanation, talk to your team!
  • 20.
    • You shall not expect no errors at all
  • 21.
    • You shall not expect no errors at all
    • Testing is not a “formal verification technique”
    • You can not say anything about what it is not tested… that is why it is important to write the test first
    • DO NOT STOP DOING TDD because you got some errors on production
    • Use Mutation Testing/Coverage to test your tests!!
  • 22.
    • You shall not expect one hundred percent coverage
  • 23.
    • You shall not expect one hundred percent coverage
    • Sometimes it is too costly to automatize certain tests
    • Coverage is not a good measure of testing quality
    • 100% coverage is impossible when just starting to do TDD
  • 24.
    • You shall not remove the QA team due to TDD
  • 25.
    • You shall not remove the QA team due to TDD
    • Because TDD is not about testing only!
    • Because TDD does not test UI, user experience, performance, scalability, etc, etc
    • TDD helps QA to concentrate on the real and important issues
  • 26.
    • You shall wait for your team to be “test infected”
  • 27.
    • You shall wait for your team to be “test infected”
    • Experience is IMPORTANT. Wait your team to become expert, it will not happen in a week
    • Do not mix senior programmers with junior programmers, but semi-senior programmers with both (Pragmatic thinking and learning)
  • 28.
    • The Technical Commandments
  • 29.
    • You shall write the test first
  • 30.
    • You shall write the test first
    • Is about incremental design and programming
    • Is not about providing a generic implementation with one case
    • It is not only about not doing what is not necessary
    • If you don’t do it, you will lie to yourself and forget to write some tests
    • If you don’t do it, you are just testing
    • IT IS THE MOST DIFICULT PART
  • 31.
    • You shall assert in your tests
  • 32.
    • You shall assert in your tests
    • Test without assertion is not a test, it is just a mere observation
    • If you don’t have an assertion, re-think the whole test or remove it
  • 33.
    • You shall not write many tests and then try to run them
  • 34.
    • You shall not write many tests and then try to run them
    • Use a notepad to write the description of the tests that came to your mind
    • Wrong design decisions (which is common when not knowing the whole picture) will affect all the tests you wrote
    • You have to start feeling comfortable with the “uncertainty”… it is about incremental design/programming
  • 35.
    • You shall not believe that TDD is about unit testing only
    • (with classical definition of unit testing)
  • 36.
    • You shall not believe that TDD is about unit testing only
    • TDD is not only about testing a method or a class
    • The more important tests are those that verify a functionality of the system
    • Unit Test = Run fast! (less than 100 milliseconds)
  • 37.
    • You shall not name your tests after the HOW but after the WHAT
  • 38.
    • You shall not name your tests after the HOW but after the WHAT
    • Wrong name: testAccountBalance
      • Too generic, it is not a concrete example
    • Good name: testGivenAnAccountWithoutTransactionsWhenAskedForItsBalanceThenItShouldReturnCero It is a concrete example
    • Test names are LONG! and they should be
  • 39.
    • You shall verify one case per test
  • 40.
    • You shall verify one case per test
    • To keep tests simple
    • If a test fails the you know by the test name what it is wrong
    • It is difficult to name a test that verifies more than one case  smell
  • 41.
    • You shall not test twice the same
  • 42.
    • You shall not test twice the same
    • To simplify test maintenance
    • To keep consistency
  • 43.
    • You shall keep your tests clean, they are another system
  • 44.
    • You shall keep your tests clean, they are another system
    • The tests are another system using yours!
    • Test maintenance can get costly if you don’t keep them clean
  • 45.
    • You shall not start testing interfaces, you shall start testing the business model
  • 46.
    • You shall not start testing interfaces, you shall start testing the business model
    • Because you have to start with the simplest test possible
    • Because you want immediate feedback
    • Because is the business model what is important regardless any interface (UI, rest, webservices, etc)
  • 47.
    • You shall not TDD using relational databases
  • 48.
    • You shall not TDD using relational databases
    • Relational databases are SLOW (from a testing point of view)
    • Relational databases make your development harder
    • Relational databases misguide your design
    • Relational databases are a solution to a computable problem: persistence
    • Test but not TDD using relational database
  • 49.
    • You shall not test using external systems
  • 50.
    • You shall not test using external systems
    • A Relational Database is an external system!
    • External systems make your test slow
    • External systems avoid your test to be in “control of everything”
    • External systems create an unnecessary coupling with your tests
    • Simulate external systems
  • 51.
    • You shall not mock your wife!
  • 52.
    • You shall not mock your wife!
    • There are certain things you should not simulate!
    • Do not simulate your business objects
    • Only simulate what is out of your system’s reach
    • If scenarios are difficult to create, create scenarios factories!
    • Object collaborate, they don’t live alone by themselves
  • 53.
    • You shall understand that TDD does not imply good design
  • 54.
    • You shall understand that TDD does not imply good design
    • Good designs are made by good designers
    • TDD implies less couple designs but not good ones
    • TDD does not imply not to think!
    • TDD does not imply not to use good design techniques or rules
  • 55.
    • You shall not worry about performance at the beginning
  • 56.
    • You shall not worry about performance at the beginning
    • You shall not worry about performance, persistence, scalability, etc. (the computational problems)
    • You shall worry about modeling the business first!
  • 57.
    • You shall love testing as much as programming
  • 58.
    • You shall love testing as much as programming
    • Because as programmers, we always test We do it implicitly We do it in our heads
    • Testing is part of development
    • GOOD PROGRAMMER = GOOD TESTER
  • 59.
    • And now the joke…
  • 60.
    • The ten commandments
    • I am TDD your Development Technique; you shall not have strange techniques before me.
    • You shall not take the name of TDD, your Development Technique, in vain.
    • Remember to keep holy all days to TDD
    • Honor your tests and your programs.
    • You shall not kill QA
  • 61.
    • The ten commandments
    • You shall not commit adultery forgetting to write the test first
    • You SHALL steal other test ideas
    • You shall not bear false witness against TDD if you have not try it.
    • You SHALL covet your neighbor's tests.
    • You shall not covet your neighbor's lack of testing.
  • 62.
    • We teach this and other important design aspects in our courses
    • Advance Design with OO : Nov 14 th
    • TDD : Oct 25 th , Nov 22 nd
    • Check them out at:
    • http://www.10pines.com/content/cursosdisponibles
  • 63. Questions?
  • 64.
    • Muchas gracias!
    [email_address] www.10Pines.com twitter: @10Pines Argentina Tel.: +54 (11) 4780-2460 Paraguay 523, 7N Buenos Aires