Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Cargando en…3
×

Eche un vistazo a continuación

1 de 138 Anuncio

Más Contenido Relacionado

Presentaciones para usted (18)

A los espectadores también les gustó (20)

Anuncio

Similares a Testing smells (20)

Más reciente (20)

Anuncio

Testing smells

  1. 1. aninda kundu spacefugitive @aninda42
  2. 2. 2008
  3. 3. 
  4. 4. sidu ponnappa kaiwren @ponnappa
  5. 5. 2006
  6. 6. any_instance
  7. 7. any_instance that’s right - it’s an antipattern
  8. 8. wrest
  9. 9. wrest 'http://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 testing cukes, 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 types just for this talk, yeah? not formal, like.
  39. 39. implementation / workflow
  40. 40. implementation / workflow what’s in the test / how it was written
  41. 41. { implementation anti-patterns }
  42. 42. The long test The test with too many assertions
  43. 43. The long test file
  44. 44. The long test file
  45. 45. The long test file Refactor: 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 terminology name/descriptor should say it all
  51. 51. the test with arcane terminology name/descriptor should say it all treat these as developer documentation
  52. 52. the test with arcane terminology name/descriptor should say it all treat these as developer documentation people rolling onto a project <3 you for it
  53. 53. the test with arcane terminology name/descriptor should say it all treat these as developer documentation people rolling onto a project <3 you for it comment = well named test
  54. 54. The slow test
  55. 55. the slow test too much data ? (again, fixtures or heavy setup)
  56. 56. The slow test too much data ? (again, fixtures or heavy setup) up next..
  57. 57. The slow test too much data ? (again, fixtures or heavy setup) up next.. Too many objects (running into MRI GC?)
  58. 58. The slow test Too much data ? (again, fixtures or heavy setup) up next.. Too many objects (running into MRI GC?) profile and fix
  59. 59. The slow test Too 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 test Too 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 test Too 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 test Too 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 setup Fixtures are for static data only
  65. 65. The test that has complex setup Fixtures are for static data only Large factory setups are better than invisible fixtures
  66. 66. The test that has complex setup Fixtures are for static data only Large 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 tests Rule 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 fail Red-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. refactor b692246bad
  80. 80. refactor b692246bad 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. { reading between the lines }
  101. 101. text subtext
  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 coverage that’s from all those Cukes we just told you about
  106. 106. we love our tests we run them at least once every day
  107. 107. we keep our build green
  108. 108. we keep our build green we 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 work we 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 

Notas del editor

  • \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&amp;#x2019;s the difference.\n
  • Ask them what&amp;#x2019;s the difference.\n
  • Ask them what&amp;#x2019;s the difference.\n
  • \n
  • Ask them what&amp;#x2019;s the difference.\n
  • Lets start with a few well understood facts about our community which help set some context - we&amp;#x2019;ll circle back to them later\n
  • we&amp;#x2019;re all agilists. I haven&amp;#x2019;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&amp;#x2019;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&amp;#x2019;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&amp;#x2019;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&amp;#x2019;s the subtext - which I&amp;#x2019;ll mention where appropriate\n
  • \n
  • Ask them what&amp;#x2019;s the difference.\n
  • Ask them what&amp;#x2019;s the difference.\n
  • Ask them what&amp;#x2019;s the difference.\n
  • Ask them what&amp;#x2019;s the difference.\n
  • Ask them what&amp;#x2019;s the difference.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

×