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.

Like this presentation? Why not share!

Like this? Share it with your network

Share

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

  • 3,577 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
3,577
On Slideshare
3,572
From Embeds
5
Number of Embeds
1

Actions

Shares
Downloads
21
Comments
0
Likes
1

Embeds 5

http://www.slideshare.net 5

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