Testing smells

1,533 views

Published on

http://rubyconfindia.org/2012/talks.html

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,533
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • blah blah contributed to rspec blah blah\n
  • \n
  • contributed an anti pattern to rspec\n
  • \n
  • \n
  • \n
  • \n
  • Ask them what’s the difference.\n
  • Ask them what’s the difference.\n
  • Ask them what’s the difference.\n
  • \n
  • Ask them what’s the difference.\n
  • Lets start with a few well understood facts about our community which help set some context - we’ll circle back to them later\n
  • we’re all agilists. I haven’t come across a single waterfall Ruby shop - or not one that claims this publicly. Agile is all about short feedback loops allowing you to deliver high quality software while dealing with change.\n
  • Pairing is much less common - but accepted.\n
  • Pairing is much less common - but accepted.\n
  • Everyone writes tests now. Nobody will publicly state that they explicitly consider testing and/or TDD a low value activity or worse, a complete waste of time.\n
  • Lets start with a few well understood facts about building software\n
  • new codebases are awsome. so beautiful...\n
  • then it’s jenga\n
  • and anyone working on it winds up like the good prince\n
  • And because these things are true, we try to solve the problem with tests\n
  • Short feedback cycles are important. It’s like a friendly kitty giving you feedback about code that needs petting.\n
  • Lengthen your feedback cycles and what you learn when the feedback hits you will be like having a royal bengal tiger jump on you while you’re in a pool. Seriously.\n
  • And because these things are true, we try to solve the problem with tests\n
  • And because these things are true, we try to solve the problem with tests\n
  • And because these things are true, we try to solve the problem with tests\n
  • And because these things are true, we try to solve the problem with tests\n
  • And because these things are true, we try to solve the problem with tests\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • A Test should have only one reason to fail and therefore ideally make just one assertion.\n
  • \n
  • \n
  • \n
  • \n
  • Tests are supposed to be simple, easy to read and understand.\nAre you going to write a test that tests your test? Then avoid logic in tests.\n\n
  • \n
  • \n
  • \n\n
  • \n\n
  • \n\n
  • If your code does not have behaviour, dont test it. Its totally fine to skip it\n
  • \n\n
  • \n\n
  • \n\n
  • \n\n
  • \n\n
  • Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
  • \n\n
  • \n\n
  • \n\n
  • \n\n
  • \n\n
  • \n\n
  • \n\n
  • \n\n
  • Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
  • Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
  • Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
  • Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
  • \n
  • \n
  • Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
  • Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
  • Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
  • Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
  • Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
  • Testing is used for quick feedback to the developer. \n\nSlow test suites are run less often. \n\nSkipping test run can cause a dev to spend more time in retracing their steps to figure out what broke the tests since they had them passing last.\n\nIts worth finding out which your slowest tests are and optimizing them.\n\n
  • \n
  • \n
  • This is rule number 1\n
  • raaad\n
  • gureeen\n
  • reefactor\n
  • better yet\n
  • \n
  • \n
  • \n
  • \n
  • red-green-commit-refactor-commit\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • So - back to what you hear about testing. Here are some of the common things bandied about in the industry, with some subtext about what it usually means.\n
  • then there’s the subtext - which I’ll mention where appropriate\n
  • \n
  • Ask them what’s the difference.\n
  • Ask them what’s the difference.\n
  • Ask them what’s the difference.\n
  • Ask them what’s the difference.\n
  • Ask them what’s the difference.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Testing smells

    1. 1. aninda kunduspacefugitive @aninda42
    2. 2. 2008
    3. 3. 
    4. 4. sidu ponnappakaiwren @ponnappa
    5. 5. 2006
    6. 6. any_instance
    7. 7. any_instancethat’s right - it’s an antipattern
    8. 8. wrest
    9. 9. wresthttp://google.com.to_uri(:follow_redirects => false).get
    10. 10. started two companies
    11. 11. started two companies over five years
    12. 12. 
    13. 13. { context }
    14. 14. pair programming
    15. 15. stand-ups
    16. 16. TDD
    17. 17. { facts }
    18. 18. O SHIT!
    19. 19. feedback!
    20. 20. changing code is tough +feedback loops should be short
    21. 21. { tests! }
    22. 22. no, not those
    23. 23. yeah, those
    24. 24. choices!
    25. 25. watir? TDD? functional? cucumber? rspec?BDD? minitest? shoulda? integration? regression? unit?
    26. 26. full-to confusion for beginners
    27. 27. still a little confusing for the experienced
    28. 28. a good place to start?
    29. 29. a good place to start? unit tests
    30. 30. this talk is about unit testingcukes, capybara, selenium et. al. are out of scope
    31. 31. we also thought...
    32. 32. lets analyse the situation by looking at the villains
    33. 33. after all, a good villain is a sexy thang!
    34. 34. after all, a good villain is a sexy thang! makes you want to be the hero
    35. 35. like this guy
    36. 36. so this talk is about unit testing anti-patterns
    37. 37. { two types }
    38. 38. two typesjust for this talk, yeah? not formal, like.
    39. 39. implementation / workflow
    40. 40. implementation / workflowwhat’s in the test / how it was written
    41. 41. { implementation anti-patterns }
    42. 42. The long testThe test with too many assertions
    43. 43. The long test file
    44. 44. The long test file
    45. 45. The long test fileRefactor: extract multiple classes
    46. 46. The test that has logic
    47. 47. who watches the watchmen?
    48. 48. The implementation bound test
    49. 49. the test with arcane terminology
    50. 50. the test with arcane terminologyname/descriptor should say it all
    51. 51. the test with arcane terminology name/descriptor should say it alltreat these as developer documentation
    52. 52. the test with arcane terminology name/descriptor should say it alltreat these as developer documentationpeople rolling onto a project <3 you for it
    53. 53. the test with arcane terminology name/descriptor should say it alltreat these as developer documentationpeople rolling onto a project <3 you for it comment = well named test
    54. 54. The slow test
    55. 55. the slow testtoo much data ? (again, fixtures or heavy setup)
    56. 56. The slow testtoo much data ? (again, fixtures or heavy setup) up next..
    57. 57. The slow testtoo much data ? (again, fixtures or heavy setup) up next.. Too many objects (running into MRI GC?)
    58. 58. The slow testToo much data ? (again, fixtures or heavy setup) up next.. Too many objects (running into MRI GC?) profile and fix
    59. 59. The slow testToo much data ? (again, fixtures or heavy setup) up next.. Too many objects (running into MRI GC?) profile and fix Testing externals?
    60. 60. The slow testToo much data ? (again, fixtures or heavy setup) up next.. Too many objects (running into MRI GC?) profile and fix Testing externals? Stop it! Stub it!
    61. 61. The slow testToo much data ? (again, fixtures or heavy setup) up next.. Too many objects (running into MRI GC?) profile and fix Testing externals? Stop it! Stub it! Rails startup time !@#$?
    62. 62. The slow testToo much data ? (again, fixtures or heavy setup) up next.. Too many objects (running into MRI GC?) profile and fix Testing externals? Stop it! Stub it! Rails startup time !@#$? Spork, Guard
    63. 63. The test that has complex setup
    64. 64. The test that has complex setupFixtures are for static data only
    65. 65. The test that has complex setup Fixtures are for static data onlyLarge factory setups are better than invisible fixtures
    66. 66. The test that has complex setup Fixtures are for static data onlyLarge factory setups are better than invisible fixtures Stub non essential factories
    67. 67. All tests should execute independantly as well as a suite
    68. 68. All tests should execute independantly as well as a suite tests must not share state
    69. 69. Avoid redundant / replicated tests
    70. 70. Avoid redundant / replicated tests Push tests down the order as much as possible e.g. Controller tests that can exist as model testsRule of thumb : Do this as long as you can keep the name of the test almost the same
    71. 71. The test that shows high churn
    72. 72. The test that cannot failRed-green refactor. Make sure the test fails first.
    73. 73. { workflow anti-patterns }
    74. 74. TEST LAST
    75. 75. #1
    76. 76. refactor
    77. 77. #1.1
    78. 78. b692246bad
    79. 79. refactorb692246bad
    80. 80. refactorb692246bad 0df4e19f2a
    81. 81. TESTING ONLY FOR REGRESSION
    82. 82. usually test last
    83. 83. TDD helps encapsulate
    84. 84. TESTING ELSWHERE
    85. 85. separate teams of testers writing unit tests
    86. 86. ONLY RUN RAKE
    87. 87. means you’re never working on just one unit
    88. 88. NEVER RUN RAKE
    89. 89. without CI you’re in a world of pain
    90. 90. ONLY RUN TEST(S) FROM CLI
    91. 91. slower, less productive
    92. 92. QA TEAM FOR BUSINESS LOGIC VERIFICATION
    93. 93. your tests should be enough
    94. 94. NO CI
    95. 95. test frequently (every commit!)
    96. 96. feedback for distributed/large teams
    97. 97. CI servers are collaboration tools
    98. 98. MANUAL DEPLOY TO STAGING
    99. 99. don’t trust your commits
    100. 100. { readingbetween the lines }
    101. 101. textsubtext
    102. 102. we do BDD, not TDD
    103. 103. we do BDD, not TDD we only write Cukes
    104. 104. we have 100% code coverage
    105. 105. we have 100% code coveragethat’s from all those Cukes we just told you about
    106. 106. we love our testswe run them at least once every day
    107. 107. we keep our build green
    108. 108. we keep our build greenwe comment out failing tests if that’s what it takes
    109. 109. tests are an integral part of the way we work
    110. 110. tests are an integral part of the way we workwe write them for every client that wants them
    111. 111. Attributions•Agile Pills: http://briannoyle.wordpress.com/2009/05/12/getting-yer-agile-on-at-a-discount-upcoming-course•TDD index card: http://www.testically.org/2011/01/12/the-ideal-use-case-to-give-tdd-a-try/•Pair programming: http://thoughtworker.com/agile-our-way-life•Stand-up: http://www.flickr.com/photos/karthikc/333796551/•C# : http://www.jameswiseman.com/blog/tag/c-sharp/•Robotic arm : http://profmason.com/?p=562•Wrecking ball: http://marilebetterdays.wordpress.com/2012/02/28/wrecking-ball-lyrics-the-title-track/•Cat eat finger: http://www.123rf.com/photo_2005824_cat-eating-human-finger.html•Tiger attack: http://tvmywifewatches.blogspot.com/2011/07/rhw-of-nj-pointcounterpoint-should-kim.html•Lex Luthor: http://maxnaylor.ca/?attachment_id=835•The Joker: http://www.fanpop.com/spots/the-joker/images/9028188/title/joker
    112. 112. 42@ponnappa @aninda42 

    ×