• Like

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

TestBrowser Driven Development: How to get bulletproof code from lazy developers

  • 2,253 views
Uploaded on

Introducing a new coding technique that helped PretaWeb deliver a large workflow system on time, on budget and most importantly, delivered what we expected to deliver. …

Introducing a new coding technique that helped PretaWeb deliver a large workflow system on time, on budget and most importantly, delivered what we expected to deliver.

This will cover

• unit and doctest in python,
• test driven development,
• usecase analysis,
• automated functional web testing,
• some practical examples using Grok and
• a brief look at documentation driven development.
Techniques covered are applicable to small and large web developments

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,253
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
22
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. TestBrowser Driven Development How to get bulletproof code from lazy developers Dylan Jay [email_address]
  • 2.
    • Dylan Jay
    • 3. 6 years with Plone
    • 4. Large corporate Java/Rational Unified process background
    • 5. Co-founder of PretaWeb in Australia
    • 6. Started pretaweb.funnelweb, collective.hostout, Products.LoginLockout (and way way back RemoteUserFolder)
    About me
  • 7. What this talk is about
    • Story of how we delivered the difficult (previous failures)
    • 8. Communication
    • 9. Users ↔ Business Analyst
    • 10. Business Analyst ↔ Developers
    • 11. For project managers, business analysts, technical leads
    • 12. But also for solo development
  • 13. The story begins...
    • Gov. department
    • 14. Complex Workflow Application of sensitive info – generating certificates
    • 15. BA 40% Dev 60% + support
    • 16. Fixed price + fixed deadline.
    • 17. Sold them on scrum … without mentioning scrum
    • 18. Used hybrid SCUM + usecase analysis
  • 19. Roles: reference
    • BA: Business Analyst - Extract requirements from client and produce requirements document. Traditionally job ends before code begins
    • 20. PO: Product Owner - In SCRUM: Sort of like a BA who sticks around. Go to person.
    • 21. Dev: Developer - People who want solve code problems not user problems :)
    • 22. ST/QA: System Tester - Non-developers there to break developers work
  • 23. CRC Card sessions
    • Class, Responsibility, Collaboration
  • 24. Use-case analysis
      Great for workflow/edge cases
    • Usecase:
      • 1 main scenario (sunny day)
      • 25. ~30 alternate scenarions (rainy day)
    • Challenge - level of detail
      • Premature detail vs. not enough
    • ~50 scenarios
    • 26. 43 page word doc including non-functional requirements
  • 27. Paper Based Prototype
    • http://www.balsamiq.com/products/mockups
  • 28. Stories vs Usecases
    • We used SCRUM
    • 29. SCRUM uses Stories
    • 30. Stories are good for estimation
    • 31. Stories group functionality vs. Scenarios runs across functionality
    • 32. We
      • Broke large scenario into three stories
      • 33. Grouped 3-4 related scenarios into stories
  • 34. Unit Testing
    • Tests are code
    • 39. Test functions/API
    • 40. Tests run fast
    • 41. Tests run often
    • 42. Tests run after every change
  • 43. Unit Testing – scorecard
    • Communication of requirements - x
    • 44. Validation of requirements – x
    • 45. Prevent regressions - ✓
  • 46. Doctests
    • Structured text document
    • 47. Tells a story
    • 48. Tells a story with EXAMPLES THAT WORK!
    • 49. Code interleaved
    • 50. Output checked against actual == test
    • 51. docstring or standalone doctests
  • 52. Functional Testing
    • Test system from outside – GUI after development
    • 53. Written from user perspective
    • 54. Easy to write – write it as you would use it
    • 55. Usecase = test
    • 56. Often done by separate team – system testers
    • 57. Often done just before delivery
    • 58. Example: selenium
  • 59. Selenium
  • 60. zc.testbrowser an api browser Easy to keep in your head – fun - natural browser.getControl( label=None, name=None, index=None ) /.options /.value /.click() browser.getLink( text=None, url=None, id=None ) /.click() browser.open(url) brower.goBack() browser.reload() print browser.contents
  • 61. Usecases to tests
    • Dev: Branch created
    • 62. Dev: Scenarios copied to StoryX.txt
    • 63. Dev: Code developed
    • 64. Dev: StoryX.txt augmented with testbrowser
    • 65. Dev: All Tests pass
    • 66. PO: Code + test reviewed
    • 67. PO: Branch merged
  • 68. TestBrowser extras
    • Doesn't do javascript
    • 69. But zc.testbrowser.real does
      • Requires firefox
    • Zope.testrecorder
      • Generate tests from GUI
    • With Plone use roadrunner
  • 70. Still not working...
    • Implemented wrong thing – rework
    • 71. Usecases not detailed enough
    • 72. Lazy BA – didn't want tell developers how to do it
    • 73. Lazy developers – didn't want at the user level
  • 74. Functional Test Driven Development
    • PO: Branch created
    • 75. PO: Scenarios copied to StoryX.txt
    • 76. PO: StoryX.txt augmented with tests (sort of)
    • 77. Dev: Code developed
    • 78. Dev: Test finished off
    • 79. Dev: All tests pass
    • 80. PO: Code + test reviewed
    • 81. PO: Branch merged
  • 82. Our process – Bugs
    • Dev: Branch created
    • 83. Dev: StoryX.txt add in bug condition
    • 84. Dev: Show test fails
    • 85. Dev: Code fixed
    • 86. Dev: All tests pass
    • 87. PO: Code + test reviewed
    • 88. PO: Branch merged
  • 89. Test Driven Development
    • Write tests before code
    • 96. red/green/refactor
      • First fail then fix
    • Forces you to understand requirements before writing code
  • 97. TestBrowser Driven Development
    • Communication of requirements - ✓
      • Level of detail right
    • Easy – ✓
      • Technical PO can do it in reasonable time
    • Validation of requirements – ✓
      • Easy to see changes to tests
    • Prevent regressions - ✓
      • Test suite run after any change e.g. 1862 bug
  • 98. Example: URL Shortener
  • 99. Proposal: Screenshot gen
    • Testbrowser statements -> screenshot
    • 100. Highlight action or comparison in screenshot
    • 101. Doctests with pictures and no code
    • 102. A better pypi & Plone Software Center
    • 103. Documentation Driven Development
  • 104. Conclusion
    • ~50 usecases
      • all turned into doctests and extended
      • 105. Living requirements/documention
    • Quality was very important
      • delivered with peace of mind
    • Tight deadline, tight budget
      • delivered on time on budget
    • Lazy developers
      • less rework, less delays = $$$
  • 106. Credits http://docs.python.org/library/doctest.html http://pypi.python.org/pypi/zc.testbrowser http://plone.org/documentation/tutorial/testing/functional-tests