Your SlideShare is downloading. ×
Testing Workshop
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Testing Workshop

1,822
views

Published on

Background slides used during live demo of test driven development in python.

Background slides used during live demo of test driven development in python.

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,822
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
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. Testing Workshop Author: Michael Dunstan <michael@elyt.com> Version: 1.2 Licence: Creative Commons Attribution-Share Alike 3.0
  • 2. Other hands-on introductions to testing Chapter 9: Unit Testing of Dive Into Python 3 by Mark Pilgrim Introduction to unittest - Starting Testing with Python by Michael Foord Dingus Screencast: A mock/stub library with automatic isolation by Gary Bernhardt.
  • 3. virtualenv Provides a nicely isolated Python environment for running the demonstration. Installation the virtualenv tool: $ easy_install virtualenv Create an isolated Python environment: $ virtualenv --no-site-packages test-demo Activate this new environment: $ source test-demo/bin/activate Using version 1.4rc1 of virtualenv.
  • 4. nose Test discovery, loading and running. Customisable through the use of plugins. Less boiler plate code than unittest. Installation: easy_install nose Minimal test: from nose.tools import assert_equals def test_simple_addition(): assert_equals(1+1, 2) See Testing with nose. Using version 0.11.1 of nose.
  • 5. FizzBuzz Exercise: play the FizzBuzz game. Write a program that: Prints the numbers from 1 to 100. But for multiples of 3 print "Fizz" instead of the number. And for the multiples of 5 print "Buzz". For numbers which are multiples of both 3 and 5 print "FizzBuzz".
  • 6. Short life cycle highly repeated
  • 7. NoseGrowl Example of using a nose plugin. Hooks into system wide notification tool. Growl on OS X. Installation: easy_install NoseGrowl Usage nosetests --with-growl
  • 8. setup.cfg Put all your regular command line options into a config file setup.cfg: [nosetests] verbose=True with-growl=1
  • 9. doctest Execute code samples: >>> a = 1 >>> b = 2 >>> a + b 3 Include doctests in test runs using: [nosetests] ... with-doctest=True doctest-extension=txt Which also picks up doctests from files such as README.txt See doctest.
  • 10. doctest options Inline comments in the doctest: >>> print('Hello world') #doctest: +ELLIPSIS Hello ...d Other useful options include: #doctest: +REPORT_UDIFF #doctest: +NORMALIZE_WHITESPACE See doctest - Option Flags and Directives.
  • 11. doctest warts Yikes: >>> 0.03 0.029999999999999999 >>> {'a': 1, 'b': 2, 'c': 3} {'a': 1, 'c': 3, 'b': 2} See Narrative tests are lousy unit tests and Tests are code, doctests aren't. However I like doctests.
  • 12. FizzBuzz 1.1 For the number 9 print the current time and date. This is a forced example to demonstrate the use of mock.
  • 13. mock Replace real objects used by your code with mock objects. Mock objects can be configured to respond in specific ways. After performing an action, you can make assertions about which methods / attributes were used and arguments they were called with. The important thing with patching is that you patch the namespace where the object is used and not where it is defined. Installation: easy_install mock See Mock - Mocking and Testing Library. Using version 0.5.0 of mock.
  • 14. coverage Installation: easy_install coverage Generate coverage data: nosetests --with-coverage --cover-html --cover-package fizzbuzz Then view the coverage reports: open cover/index.html Using version 3.1 of coverage.
  • 15. Test metrics Total test count — more tests are better. LOC for application code verses LOC for the tests. SQLite is currently claiming 709 times as much test code and test scripts than the application code base itself. See How SQLite Is Tested. Test coverage — larger coverage is better. But 100% coverage only means that you have reached the end of the limits of the coverage tool.
  • 16. FizzBuzz code See http://bitbucket.org/dunny/fizzbuzz/src/

×