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

The ten commandments of TDD

on

  • 980 views

 

Statistics

Views

Total Views
980
Views on SlideShare
976
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 The ten commandments of TDD Presentation Transcript

  • The Ten Commandments of TDD Hernán Wilkinson Agile 2011
    • What is TDD?
    • This is NOT TDD, this is how you do it!
    So… what is the ESENCE of TDD
    • TDD is not about testing only
    • It is more than that…
    • TDD is about doing incremental problem solving guided by concrete examples
    • We are use to incremental development (cycles/iteration), but not incremental design/programming
    • TDD brings testing to development cycle
    Analisys Design Program. Testing
    • TDD brings testing to development cycle
    Analisys Design Program. Testing
    • 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!
    • TDD SINCERIZA programmers about testing
    • A programmer that is not a good tester is not a good programmer
    • Good Programmer = Good Tester
    =
    • TDD is a cultural change… a big one
    • The Commandments
    • Management ones
    • Technical one
      • About testing
      • About design
    • (Sadly, they are more than ten…)
    • The Management Commandments
    • You shall not expect your developers do TDD because it is God, I mean Good 
    • 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!
    • You shall provide time to do TDD
    • 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
    • You shall not send mixed messages stopping TDD when time looks not enough
    • 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!
    • You shall not expect no errors at all
    • 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!!
    • You shall not expect one hundred percent coverage
    • 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
    • You shall not remove the QA team due to TDD
    • 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
    • You shall wait for your team to be “test infected”
    • 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)
    • The Technical Commandments
    • You shall write the test first
    • 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
    • You shall assert in your tests
    • 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
    • You shall not write many tests and then try to run them
    • 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
    • You shall not believe that TDD is about unit testing only
    • (with classical definition of unit testing)
    • 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)
    • You shall not name your tests after the HOW but after the WHAT
    • 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
    • You shall verify one case per test
    • 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
    • You shall not test twice the same
    • You shall not test twice the same
    • To simplify test maintenance
    • To keep consistency
    • You shall keep your tests clean, they are another system
    • 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
    • You shall not start testing interfaces, you shall start testing the business model
    • 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)
    • You shall not TDD using relational databases
    • 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
    • You shall not test using external systems
    • 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
    • You shall not mock your wife!
    • 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
    • You shall understand that TDD does not imply good design
    • 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
    • You shall not worry about performance at the beginning
    • 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!
    • You shall love testing as much as programming
    • 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
    • And now the joke…
    • 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
    • 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.
    • 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
  • Questions?
    • Muchas gracias!
    [email_address] www.10Pines.com twitter: @10Pines Argentina Tel.: +54 (11) 4780-2460 Paraguay 523, 7N Buenos Aires