scryent: plone - hone your test fu
DESCRIPTION
Learn about the basics of test-driven development using Plone. Presented by Jordan Baker from Scryent at the Plone Symposium East 2009.TRANSCRIPT
Hone Your TestFuA Test-First Approach
Presented By: Jordan Baker, Scryent.comPlone Symposium East, Penn State 2009
Image CC Encyclopedia Britannica
Why test?
• prevents software regressions
• improves code quality
• provides the best developer documentation
• tests passing is proof that you delivered what you were contracted to produce
• business measurement help prevent scope creep
• finding bugs early makes them cheaper to fix
Test First!
• writing tests first forces you to get clear about requirements up front
• generally results in more modular and reusable code
• facilitates a conversation with your product owners
• manual testing is slow and error-prone! The longer you put off writing tests the less efficient you are.
Unit Tests
• fast
• tests implementation of a sliver of behaviour
• doesn't rely on any external resources (so use mocks or fakes for external resources)
• lots of these
• use unittest or doctest modules for this
Integration / Functional Tests
• test the integration of various components and the flow in and out of your code
• use PloneTestCase
UI Tests
• End to end tests
• Typically black-box tests that act as an end-user would
• inherently brittle as the UI often changes
• zope.testbrowser, selenium, windmill, etc
Python and Plone testing frameworks + tools
• Python unittest module
• Plone Test Case
• plone.reload
• roadrunner
• Mocker
• zope.testbrowser
Requirements
• User can visit the demo page and type in their name
• The user will receive a greeting in the format "Hello, <name>"
Where to start?
• Time to write your first test.
• There are some excellent docs on working with Plone from Python: http://plone.org/documentation/tutorial/manipulating-plone-objects-programmatically
• Take your time, write out what you’re trying to in English first before coding.
Writing your first test
• Let’s write a unit test for this feature: The user will receive a greeting in the format "Hello, <name>"
• To unit test this we will instantiate the View class which represents the data for this page, pass the username and check the result.
Using Zope's testtrunner
• TIP: run only the test you need to run$ bin/instance test -s your.module -t test_something
• By using -s you can specify the module to look for tests.
• If you want to run only one particular test method then use -t to specify which one.
• In our case the command will be:
$ bin/instance test -s pse09.demo
Make it faster... enter roadrunner
• Roadrunner is a tool that preloads Plone to make running your integration tests much much faster.
• Its easy to use too. Just add roadrunner to your buildout.cfg like so:
• Roadrunner accepts the same command line arguments as Zope testrunner. So we can run our tests like this:
$ bin/roadrunner -s pse.demo
Pdb-fu (debugging)
• Getting test failures from Zope Testrunner? Use -D to drop you into Pdb using post-mortem debugging
• Use pdb’s jump command to re-run certain lines of codes. Watch out for side-effects.
• Special variable __return__ is set. Use “continue” to go to the end of the method and then you can easily examine the return result.
• Breakpoint variables. Looping through 1000 items, set a breakpoint with an expression.
• Missing source code? This could help, add to your buildout.cfg: [buildout] unzip = true
Additional Requirements
• If a user named “Plone” submits their name they will see the message “You ROCK, Plone”
• Use plone.reload to try out these changes live, writing more tests not necessary.
using zope.testbrowser
• Test something like so:
• Go to the page @@greet
• Type in your name: Bob
• Expect to see “Hello, Bob”
Don’t Test Too Much
• Tests are software too and must be maintained.
• Too many tests makes running your entire test suite slow.
• Remember the pyramid. Just like the food pyramid you want to focus on having lots of tests from the lower levels which run quickly, and fewer from the top of the pyramid.
• Some people are opportunistic testers. They will write a minimal test for the main path of their code and then only write additional tests if regressions are found.
Some Resources
• Plone Testing tutorial: http://plone.org/documentation/tutorial/testing/
• roadrunner: http://pypi.python.org/pypi/roadrunner
• plone.reload: http://pypi.python.org/pypi/plone.reload
• zope.testbrowser: http://pypi.python.org/pypi/zope.testbrowser
