Rethinking Testing

674 views

Published on

Nowadays, TDD, BDD, continuous testing and other methodologies have come into our attention when developing. Yet, we barely know what needs to be tested and why are we testing it? During the talk we will go through a bunch of testing methodologies.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
674
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Rethinking Testing

  1. 1. Rethinking Testing towards your needs pablo@cuboxsa.com
  2. 2. eXtreme Programming Rspec Testing TestUnit jUnitTest Driven Development Crash Test
  3. 3. “Our highest priority is to satisfy the customer through the early and continuous DELIVERY of VALUABLE software.” The agile manifesto
  4. 4. The Customer Working Code On LowTime Cost
  5. 5. The Needs of CustomerWorking Code Acceptance Testing
  6. 6. Public Domain Wikimedia Commons
  7. 7. Design by Contract• by B. Meyer• Code enforces a contract• Language provides constraints – Before function call (Preconditions) – After function call (Post Conditions) – During all the function call (Invariants)
  8. 8. User.create! params[:user]Pre conditions:  params[:user] is not empty.Post conditions: New instance returned is successful. Raise exception w/errors otherwise.Invariants:  params[:user] is not modifiable. Database connection available.
  9. 9. Design by Contract• Few implementations: – Native in Eiffel – As add-on like: • Java “assert” • .Net code contracts• In Ruby – A.Hunt created DBC.rb (~2000) – Lost in translation
  10. 10. Code that verifies Code• Focus on the valuable outputs• Repeatable• Regression
  11. 11. jUnit• by Gamma & Beck since 1997• by the time Java was “cool”• Isolated Components• TestCases & TestSuites
  12. 12. Test Driven Development (TDD)• by Beck.• Test First Design and then program.• Small requirements.• Verify functionality w/automated tests.
  13. 13. “the programmer should let correctness proof and program grow hand in hand” E.Dijsktra 1972
  14. 14. The TDD Cycle Failing test PassingRefactor test
  15. 15. No Refactor Failing testTechnical Debt Overdose Fail to Passing Refactor test
  16. 16. Running Suite takes too long Failing test Passing Refactor test
  17. 17. “correctness concerns turn out to be a very effective heuristic guidance” E.Dijsktra 1972
  18. 18. Testing correctness - scales Acceptance As the user would do Integration The Ensamble. Unit The single component
  19. 19. By Jewgienij Bal, Wikimedia Commons
  20. 20. Plenty of ToolsFocus on Ruby Focus on Javascript• Test-Unit • QUnit• RSpec • Jasmine• Cucumber • Gerbil
  21. 21. Plenty of ToolsFocus on Ruby Focus on Javascript• Test-Unit • QUnit• RSpec • Jasmine• Cucumber • Gerbil
  22. 22. RSpec• Rails ready out-of-the-box• Acceptance testing: – Selenium driver – Capybara – spec/integration
  23. 23. What do we test?• Rails app: – Models – Controllers – Views• Additionally: – Services – Components
  24. 24. Typical setup on Rails Acceptance Integration t i n U
  25. 25. .rspec--colour--format Fuubar--profileAdditional gems: Autotest Specjour / Spork
  26. 26. Average runtime for test-suite for a small project (294 examples)25201510 seconds5 # example0 0 50 100 150 200 250 300 350
  27. 27. Two different sets of tests rspec profile10 y = 0.0033x2 - 1.6196x + 199.53 Selenium, APIs seconds y = 3E-05x2 - 0.0012x + 1.2525 # example 1 0 50 100 150 200 250 300 350
  28. 28. Models && Persistence• Object State & Transitions• Custom methods and edge conditions• Associations w/other objects• Additional Validations – Expected fields. – Factories.
  29. 29. Controllers && Views• Controllers: – Don’t test them, do acceptance tests. – Logic and state reside at Model level.• Controllers that are APIs: – Don´t test them, do integration tests.• Views – Do Acceptance testing for all actions available (not just CRUD).
  30. 30. Components• Black Box Testing: – Test parameters and results. – Test correct invoking: • Send Email: ActionMailer parameters. • Draw a chart: HighChart parameters.
  31. 31. Services• Test connectivity to services.• Mocked for Integration Tests. – Save responses in fixtures. – Assume correct/wrong responses.
  32. 32. Javascript: Selenium driver• Does a lot of things: – Creates an instance of browser. – Establishes connections. – Executes requests, renders responses. – Executes Javascript.• Emulates the user experience – Browser “bugs”
  33. 33. Slow test suite• Use a CI Server – Postpone long tests.• Avoid Rails boot time – Decouple logic from Rails into POROs. – Use a no_rails_spec_helper.• Avoid API calls lag – Mock external services.
  34. 34. Rspec By Nicolas M. Perrault , Wikimedia Commons
  35. 35. Questions?
  36. 36. спасибi¡MUCHAS GRACIAS!
  37. 37. References• The Rspec Book, D. Chelimsky et al.• TDD by Example, K. Beck• Continuous Delivery, J.Humble• The Pragmatic Programmer, A. Hunt• The Humble Programmer, E. Dijkstra http://www.cs.utexas.edu/~EWD/transcription s/EWD03xx/EWD340.html
  38. 38. Is Cucumber a need?• Rspec is good enough.• “Simplicity – the art of maximizing the amount of work not done – is essential.”• Specs are easy to program than specs + steps.• Customer Interaction vs tools.
  39. 39. Stress && Performace• Staging environment.• Monitor execution, APM: – New Relic – Air Brake
  40. 40. “…program testing can be a very effective way to show the presence of bugs, but [it] is hopelessly inadequate for showing their absence.” E.Dijsktra 1972

×