Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Testing smells

1 797 vues

Publié le

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

Publié dans : Technologie, Business
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

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 

×