Size: 37646
Comment: prefer pypi project page which appears to have more info
|
Size: 38131
Comment: fixed apycot link, apycot was moved
|
Deletions are marked like this. | Additions are marked like this. |
Line 3: | Line 3: |
Join the [[https://lists.idyll.org/listinfo/testing-in-python| Testing In Python (TIP)]] mailing list for Python testing tools discussions! | Join the [[https://lists.idyll.org/listinfo/testing-in-python|Testing In Python (TIP)]] mailing list for Python testing tools discussions! (!) This wiki page is originated from [[https://pycheesecake.org/wiki/PythonTestingToolsTaxonomy|PyCheeseCake]] and it was originally created by [[https://agiletesting.blogspot.com/2011/08/new-location-for-python-testing-tools.html|Grig Gheorghiu]] == Unit Testing Tools == ||'''Tool''' ||'''Category''' ||'''Author''' ||'''Part of''' ||'''Claim to fame''' || ||[[https://pyunit.sourceforge.net/pyunit.html|unittest]] ||unit testing ||[[https://www.pythonconsulting.com/|Steve Purcell]] ||[[https://docs.python.domainunion.de/lib/module-unittest.html|Python standard lib]] ||first unit test framework to be included in Python standard library; easy to use by people familiar with the xUnit frameworks; strong support for test organization and reuse via test suites || ||[[https://docs.python.domainunion.de/lib/module-doctest.html|doctest]] ||unit testing ||[[https://python.domainunion.de/peps/pep-0020.html|Tim Peters]] ||[[https://docs.python.domainunion.de/lib/module-doctest.html|Python standard lib]] ||copy and paste output from shell session; [[https://agiletesting.blogspot.com/2005/02/agile-documentation-with-doctest-and.html|Agile Documentation]]: unit tests themselves can serve as documentation when combined with epydoc; also see [[https://agiletesting.blogspot.com/2005/08/agile-documentation-in-django-project.html|Django's approach]] || ||[[https://codespeak.net/py/current/doc/test.html|py.test]] ||unit testing ||[[https://codespeak.net/|Holger Krekel]] ||[[https://codespeak.net/py/current/doc/home.html|py lib]] ||no API!;automatic collection of tests; simple asserts; strong support for test fixture/state management via setup/teardown hooks; strong debugging support via customized traceback || ||[[https://somethingaboutorange.com/mrl/projects/nose/|nose]] ||unittest extensions ||[[https://somethingaboutorange.com/mrl/|Jason Pellerin]] || ||unit test framework, used most notably by [[https://www.turbogears.org/|TurboGears]] and [[https://pylonshq.com/|Pylons]]; provides an alternate test discovery and running process for unittest, one that is intended to mimic the behavior of py.test as much as is reasonably possible without resorting to too much magic. More friendly with unittest.TestCase-based tests than py.test. There are also many [[https://nose-plugins.jottit.com/|plugins]] available. || ||[[https://github.com/Yelp/Testify/|testify]] ||unittest extensions ||[[https://engineeringblog.yelp.com/2010/10/now-testify.html#more|Yelp team]] || ||unit test framework, provides Enhanced test fixture setup, Split test suites into buckets for easy parallelization, PEP8 naming conventions & Fancy color test runner with lots of logging / reporting option. || ||[[https://twistedmatrix.com/trac/wiki/TwistedTrial|Trial]] ||unittest extensions ||[[https://mumak.net/|Jonathan Lange]] ||[[https://www.twistedmatrix.com/|Twisted]] ||Extension of unittest to support writing asynchronous unit tests using Deferreds and new result types ('skip' and 'todo'). Includes a command-line program that does test discovery and integrates with doctest and coverage. || ||[[https://launchpad.net/subunit|subunit]] ||unittest extensions ||[[https://launchpad.net/~lifeless|Robert Collins]] || ||Transparently adds support for running unittest test cases/suites in a separate process : prevents system wide changes by a test destabilising the test runner. It also allows reporting from tests in another process into the unittest framework, giving a single integrated test environment. || ||[[https://launchpad.net/testresources|testresources]] ||unittest extensions ||[[https://launchpad.net/~lifeless|Robert Collins]] || ||Provides a mechanism for managing 'resources' - expensive bits of infrastructure - that are needed by multiple tests. Resources are constructed and free on demand, but with an optional [[https://pycheesecake.org/wiki/TestSuite|TestSuite?]], the test run order is optimised to reduce the number of resource constructions and releases needed. Compatible with unittest. || ||[[https://launchpad.net/testtools|testtools]] ||unittest extensions ||[[https://mumak.net/wiki|Jonathan Lange]] || ||Useful extensions to unittest derived from custom extensions by projects such as Twisted and Bazaar. || ||[[https://www.mems-exchange.org/software/DurusWorks/|Sancho]] ||unit testing ||[[https://www.mems-exchange.org/|MEMS and Nanotechnology Exchange]] ||[[https://www.mems-exchange.org/software/|MEMS Exchange tools]] ||Sancho 2.1 runs tests, and provides output for tests that fail; Sancho 2.1 does not count tests passed or failed; targets projects that do not maintain failing tests || ||[[https://cheeseshop.python.org/pypi/zope.testing|zope.testing]] ||unit testing ||Zope3 community || ||Powerful test runner that includes support for post-mortem debugging of test failures. Also includes profiling and coverage reporting. This is a standalone package that has no dependencies on Zope and works just fine with projects that don't use Zope. || ||[[https://pypi.python.domainunion.de/pypi/pry|pry]] ||unit testing ||[[https://corte.si/|Aldo Cortesi]] || ||Elegant unit testing framework with built-in coverage analysis, profiling, micro-benchmarking and a powerful command-line interface. || ||[[https://pythoscope.org/|pythoscope]] ||unit testing ||[[https://joker.linuxstuff.pl/|Michal Kwiatkowski]] || ||Tool that will automatically, or semi-automatically, generate unit tests for legacy systems written in Python. || ||[[https://www.logilab.org/project/logilab-common/|testlib]] ||unittest extensions ||[[https://www.logilab.fr/|Logilab]] ||logilab-common ||Gives more power to standard unittest. More assert* methods; support for module level setup/teardown; skip test feature... || ||[[https://www.logilab.org/project/logilab-common/|pytest]] ||tests runner ||[[https://www.logilab.fr/|Logilab]] ||logilab-common ||Tests finder / runner. Selectivly run tests; Stop on first failure; Run pdb on failed tests; Colorized reports; Run tests with coverage / profile enabled... || ||[[https://pypi.python.domainunion.de/pypi/dutest|dutest]] ||unittest extensions ||[[https://simelo-en.blogspot.com/|Olemis Lang]] ||[[https://flioops.sf.net/|PyOOP package]] (distributed separately too) ||An object oriented interface to retrieve unittest test cases out of doctests. Hides initialization from doctests by allowing setUp and tearDown for each interactive example. Allows control over all the options provided by doctest. Specialized classes allow selective test discovery across a package hierarchy. || |
Line 6: | Line 27: |
(!) This wiki page is originated from [[https://pycheesecake.org/wiki/PythonTestingToolsTaxonomy | PyCheeseCake]] and it was originally created by [[https://agiletesting.blogspot.com/2011/08/new-location-for-python-testing-tools.html | Grig Gheorghiu]] | The following tools are not currently being developed or maintained as far as we can see. They are here for completeness, with last activity date and an indication of what documentation there is. If you know better, please edit. ||'''Tool''' ||'''Last Activity''' ||'''Category''' ||'''Author''' ||'''Claim to fame''' || ||[[https://testoob.sourceforge.net/|TestOOB]] ||2009 ||unittest extensions ||[[https://freshmeat.net/~oripel/|Ori Peleg]] ||unittest enhancements; test filtering via regex/glob patterns; reporting in XML/HTML; colorized output; runs pdb on failing tests; run in parallel in threads/processes; verbose asserts; report failures immediately; and a little more; || ||[[https://sourceforge.net/projects/pyunitperf|pyUnitPerf]] ||2009 ||performance-based unit testing ||[[https://agiletesting.blogspot.com/|Grig Gheorghiu]] ||port of [[https://www.clarkware.com/software/JUnitPerf.html|JUnitPerf]]; transparently adds [[https://agiletesting.blogspot.com/2004/12/performance-testing-with-pyunitperf.html|performance testing capabilities]] to existing unitttest-based test suites || ||[[https://github.com/darius/peckcheck|Peckcheck]] ||2008 ||specification-based unit testing ||[[https://wry.me/blog/|Darius Bacon]] ||like the unittest module, except that test methods may take arguments; you declare each argument with a default value which names a test-data generator and the peckcheck module will peck at your test methods with a bunch of generated values || ||[[https://code.google.com/p/testosterone/|testosterone]] ||2008 ||unit testing ||[[https://www.zetadev.com/|Chad Whitacre]] ||A manly test runner; command-line and curses(3) interfaces; the iPod of test runners. (More seriously, makes it easier to browse and inspect your test failures) || ||[[https://freshmeat.net/projects/qunittest/|qunittest]] ||2004 ||unit testing ||[[https://www.edgewall.com/|Edgewall]] ||Easy-to-use (PyQt) GUI framework and application for use with the Python unit testing framework. It can be used to conveniently execute unit tests and suites, and then display the results in a useful fashion. || |
Line 8: | Line 35: |
== Unit Testing Tools == | |
Line 10: | Line 36: |
|| '''Tool''' || '''Category''' || '''Author''' || '''Part of''' || '''Claim to fame''' || || [[https://pyunit.sourceforge.net/pyunit.html| unittest]] || unit testing || [[https://www.pythonconsulting.com/| Steve Purcell]] || [[https://docs.python.domainunion.de/lib/module-unittest.html| Python standard lib]] || first unit test framework to be included in Python standard library; easy to use by people familiar with the xUnit frameworks; strong support for test organization and reuse via test suites || || [[https://docs.python.domainunion.de/lib/module-doctest.html| doctest]] || unit testing || [[https://python.domainunion.de/peps/pep-0020.html| Tim Peters]] || [[https://docs.python.domainunion.de/lib/module-doctest.html| Python standard lib]] || copy and paste output from shell session; [[https://agiletesting.blogspot.com/2005/02/agile-documentation-with-doctest-and.html| Agile Documentation]]: unit tests themselves can serve as documentation when combined with epydoc; also see [[https://agiletesting.blogspot.com/2005/08/agile-documentation-in-django-project.html| Django's approach]] || || [[https://codespeak.net/py/current/doc/test.html| py.test]] || unit testing || [[https://codespeak.net/| Holger Krekel]] || [[https://codespeak.net/py/current/doc/home.html| py lib]] || no API!;automatic collection of tests; simple asserts; strong support for test fixture/state management via setup/teardown hooks; strong debugging support via customized traceback || || [[https://somethingaboutorange.com/mrl/projects/nose/| nose]] || unittest extensions || [[https://somethingaboutorange.com/mrl/| Jason Pellerin]] || || unit test framework, used most notably by [[https://www.turbogears.org/| TurboGears]] and [[https://pylonshq.com/| Pylons]]; provides an alternate test discovery and running process for unittest, one that is intended to mimic the behavior of py.test as much as is reasonably possible without resorting to too much magic. More friendly with unittest.TestCase-based tests than py.test. There are also many [[https://nose-plugins.jottit.com/| plugins]] available. || || [[https://github.com/Yelp/Testify/| testify]] || unittest extensions || [[https://engineeringblog.yelp.com/2010/10/now-testify.html#more| Yelp team]] || || unit test framework, provides Enhanced test fixture setup, Split test suites into buckets for easy parallelization, PEP8 naming conventions & Fancy color test runner with lots of logging / reporting option. || || [[https://twistedmatrix.com/trac/wiki/TwistedTrial| Trial]] || unittest extensions || [[https://mumak.net/| Jonathan Lange]] || [[https://www.twistedmatrix.com/| Twisted]] || Extension of unittest to support writing asynchronous unit tests using Deferreds and new result types ('skip' and 'todo'). Includes a command-line program that does test discovery and integrates with doctest and coverage. || || [[https://launchpad.net/subunit| subunit]] || unittest extensions || [[https://launchpad.net/~lifeless| Robert Collins]] || || Transparently adds support for running unittest test cases/suites in a separate process : prevents system wide changes by a test destabilising the test runner. It also allows reporting from tests in another process into the unittest framework, giving a single integrated test environment. || || [[https://launchpad.net/testresources| testresources]] || unittest extensions || [[https://launchpad.net/~lifeless| Robert Collins]] || || Provides a mechanism for managing 'resources' - expensive bits of infrastructure - that are needed by multiple tests. Resources are constructed and free on demand, but with an optional [[https://pycheesecake.org/wiki/TestSuite| TestSuite?]], the test run order is optimised to reduce the number of resource constructions and releases needed. Compatible with unittest. || || [[https://launchpad.net/testtools| testtools]] || unittest extensions || [[https://mumak.net/wiki| Jonathan Lange]] || || Useful extensions to unittest derived from custom extensions by projects such as Twisted and Bazaar. || || [[https://www.mems-exchange.org/software/DurusWorks/| Sancho]] || unit testing || [[https://www.mems-exchange.org/| MEMS and Nanotechnology Exchange]] || [[https://www.mems-exchange.org/software/| MEMS Exchange tools]] || Sancho 2.1 runs tests, and provides output for tests that fail; Sancho 2.1 does not count tests passed or failed; targets projects that do not maintain failing tests || || [[https://cheeseshop.python.org/pypi/zope.testing| zope.testing]] || unit testing || Zope3 community || || Powerful test runner that includes support for post-mortem debugging of test failures. Also includes profiling and coverage reporting. This is a standalone package that has no dependencies on Zope and works just fine with projects that don't use Zope. || || [[https://pypi.python.domainunion.de/pypi/pry| pry]] || unit testing || [[https://corte.si/| Aldo Cortesi]] || || Elegant unit testing framework with built-in coverage analysis, profiling, micro-benchmarking and a powerful command-line interface. || || [[https://pythoscope.org/| pythoscope]] || unit testing || [[https://joker.linuxstuff.pl/| Michal Kwiatkowski]] || || Tool that will automatically, or semi-automatically, generate unit tests for legacy systems written in Python. || || [[https://www.logilab.org/project/logilab-common/| testlib]] || unittest extensions || [[https://www.logilab.fr/| Logilab]] || logilab-common || Gives more power to standard unittest. More assert* methods; support for module level setup/teardown; skip test feature... || || [[https://www.logilab.org/project/logilab-common/| pytest]] || tests runner || [[https://www.logilab.fr/| Logilab]] || logilab-common || Tests finder / runner. Selectivly run tests; Stop on first failure; Run pdb on failed tests; Colorized reports; Run tests with coverage / profile enabled... || || [[https://pypi.python.domainunion.de/pypi/dutest| dutest]] || unittest extensions || [[https://simelo-en.blogspot.com/| Olemis Lang]] || [[https://flioops.sf.net/| PyOOP package]] (distributed separately too) || An object oriented interface to retrieve unittest test cases out of doctests. Hides initialization from doctests by allowing setUp and tearDown for each interactive example. Allows control over all the options provided by doctest. Specialized classes allow selective test discovery across a package hierarchy. || The following tools are not currently being developed or maintained as far as we can see. They are here for completeness, with last activity date and an indication of what documentation there is. If you know better, please edit. || '''Tool''' || '''Last Activity''' || ''' Category ''' || '''Author''' || '''Claim to fame''' || || [[https://testoob.sourceforge.net/| TestOOB]] || 2009 || unittest extensions || [[https://freshmeat.net/%7Eoripel/| Ori Peleg]] || unittest enhancements; test filtering via regex/glob patterns; reporting in XML/HTML; colorized output; runs pdb on failing tests; run in parallel in threads/processes; verbose asserts; report failures immediately; and a little more; || || [[https://sourceforge.net/projects/pyunitperf| pyUnitPerf]] || 2009 ||performance-based unit testing || [[https://agiletesting.blogspot.com/| Grig Gheorghiu]] || port of [[https://www.clarkware.com/software/JUnitPerf.html| JUnitPerf]]; transparently adds [[https://agiletesting.blogspot.com/2004/12/performance-testing-with-pyunitperf.html| performance testing capabilities]] to existing unitttest-based test suites || || [[https://github.com/darius/peckcheck| Peckcheck]] || 2008 ||specification-based unit testing || [[https://wry.me/blog/| Darius Bacon]] || like the unittest module, except that test methods may take arguments; you declare each argument with a default value which names a test-data generator and the peckcheck module will peck at your test methods with a bunch of generated values || || [[https://code.google.com/p/testosterone/| testosterone]] || 2008 || unit testing || [[https://www.zetadev.com/| Chad Whitacre]] || A manly test runner; command-line and curses(3) interfaces; the iPod of test runners. (More seriously, makes it easier to browse and inspect your test failures) || || [[https://freshmeat.net/projects/qunittest/| qunittest]] || 2004 ||unit testing || [[https://www.edgewall.com/| Edgewall]] || Easy-to-use (PyQt) GUI framework and application for use with the Python unit testing framework. It can be used to conveniently execute unit tests and suites, and then display the results in a useful fashion. || |
|
Line 39: | Line 39: |
See also [[https://garybernhardt.github.com/python-mock-comparison|here]] for a side-by-side syntax comparison between some of the more popular tools in this space. ||'''Tool''' ||'''Category''' ||'''Author''' ||'''Claim to fame''' || ||[[https://github.com/nsigustavo/ludibrio/|Ludibrio]] ||mocks, stubs, spy, and dummies ||Gustavo Rezende ||Elegant test doubles framework in Python (mocks, stubs, spy, and dummies) || ||[[https://python-mock.sourceforge.net/|Python Mock]] ||mock testing ||[[https://www.thedeveloperscoach.com/|Dave Kirby]] ||Python Mock enables the easy creation of mock objects that can be used to emulate the behaviour of any class that the code under test depends on. You can set up expectations about the calls that are made to the mock object, and examine the history of calls made. This makes it easier to unit test classes in isolation. [[https://sourceforge.net/projects/python-mock/|Download it here.]] || ||[[https://theblobshop.com/pymock|PyMock]] ||mock testing ||[[https://theblobshop.com/|Jeff Younker]] ||PyMock is based on the Java [[https://www.easymock.org/|easymock]] package. It uses a recording and replay model rather than using a specification language. Easymock lives up to its name compared to other mocking packages. PyMock takes advantage of python's dynamic nature for futher improvements. || ||[[https://www.voidspace.org.uk/python/mock.html|mock]] ||mock testing ||Michael Foord aka [[https://www.voidspace.org.uk/python/weblog/index.shtml|Fuzzyman]] ||Provides "action -> assertion" mocking patter, instead of standard "record -> replay" pattern || ||[[https://pmock.sourceforge.net/|pMock]] ||mock testing ||Graham Carlyle ||Inspired by the Java [[https://www.jmock.org/|jMock]] library, pMock makes the writing of unit tests using mock object techniques easier. Development of pmock has long since stopped and so it can be considered dead. || ||[[https://blog.ianbicking.org/minimock.html|minimock]] ||mock testing ||[[https://blog.ianbicking.org/|Ian Bicking]] ||Embeds mock testing constructs inside doctest tests. || ||[[https://oakwinter.com/code/svnmock/|svnmock]] ||mock testing ||[[https://oakwinter.com/code/|Collin Winter]] ||enables easier testing of Python programs that make use of [[https://subversion.tigris.org/|Subversion's]] Python bindings || ||[[https://labix.org/mocker|Mocker]] ||mock testing ||[[https://blog.labix.org/|Gustavo Niemeyer]] ||Graceful platform for test doubles in Python (mocks, stubs, fakes, and dummies). Well-documented and fairly feature-complete. || ||[[https://www.reahl.org/project?name=stubble|Stubble]] ||stub testing ||[[https://www.reahl.org/|Iwan Vosloo]] ||Stubble allows you to write arbitrary classes for use as stubs instead of read classes while testing. Stubble lets you link a stub class loosely to the real class which it is a stub for. This information is then used to ensure that tests will break if there is a discrepancy between the interface supported by your stub class and that of the real class it stands in for. || ||[[https://code.google.com/p/pymox/|Mox]] ||mock testing ||smiddlek, dglasser ||Mox is based on EasyMock, a Java mock object framework. Mox will make mock objects for you, so you don't have to create your own! It mocks the public/protected interfaces of Python objects. You set up your mock objects expected behavior using a domain specific language (DSL), which makes it easy to use, understand, and refactor! || ||[[https://github.com/gfxmonk/mocktest/tree/master|MockTest]] ||mock testing ||Tim Cuthbertson (gfxmonk) ||Mocktest allows you to mock / stub objects and make expectations about the methods you expect to be called as well as the arguments they should be called with. Expectations are very readable and expressive, and checked automatically. Any stubbed methods are reverted after each test case. Still under development, so subject to change || ||[[https://farmdev.com/projects/fudge/|Fudge]] ||mock and stub testing ||[[https://farmdev.com/|Kumar McMillan]] ||A module for using fake objects (mocks, stubs, etc) to test real ones. Uses a declrative syntax like jMock whereby you set up expectations for how an object should be used. An error will raise if an expectation is not met. || ||[[https://code.google.com/p/mockito/wiki/MockitoForPython|Mockito for Python]] ||mock and stub testing ||[[https://monkeyisland.pl/|Szczepan Faber]] ||A port of the [[https://code.google.com/p/mockito/|Mockito]] mocking framework to Python. (Technically speaking, Mockito is a Test Spy framework.) || ||[[https://www.texttest.org/index.php?page=capturemock|CaptureMock]] ||mock testing ||Geoff Bache ||True record-replay approach to mocking. Requires no coding, just telling it which modules/attributes you want to mock. Then stores the behaviour in an external file, which can be used to test the code without those modules installed. || ||[[https://has207.github.com/flexmock/|flexmock]] ||mock/stub/spy testing and fake objects ||[[https://github.com/has207/|Herman Sheremetyev]] ||Port of the popular Ruby mocking library to Python. Includes automatic integration with most popular test runners. || ||[[https://bitbucket.org/DavidVilla/python-doublex|doublex]] ||easy and powerful stubs, spies and mocks ||[[https://bitbucket.org/DavidVilla|David Villa]] ||Free and restricted doubles using hamcrest matchers for all assertions. It provides a wrapper for the pyDoubles framework. || |
|
Line 40: | Line 58: |
See also [[https://garybernhardt.github.com/python-mock-comparison|here]] for a side-by-side syntax comparison between some of the more popular tools in this space. | |
Line 42: | Line 59: |
|| '''Tool''' || '''Category''' || '''Author''' || '''Claim to fame''' || || [[https://github.com/nsigustavo/ludibrio/| Ludibrio]] || mocks, stubs, spy, and dummies || Gustavo Rezende || Elegant test doubles framework in Python (mocks, stubs, spy, and dummies) || || [[https://python-mock.sourceforge.net/| Python Mock]] || mock testing || [[https://www.thedeveloperscoach.com/| Dave Kirby]] || Python Mock enables the easy creation of mock objects that can be used to emulate the behaviour of any class that the code under test depends on. You can set up expectations about the calls that are made to the mock object, and examine the history of calls made. This makes it easier to unit test classes in isolation. [[https://sourceforge.net/projects/python-mock/| Download it here.]] || || [[https://theblobshop.com/pymock| PyMock]] || mock testing || [[https://theblobshop.com/| Jeff Younker]] || PyMock is based on the Java [[https://www.easymock.org/| easymock]] package. It uses a recording and replay model rather than using a specification language. Easymock lives up to its name compared to other mocking packages. PyMock takes advantage of python's dynamic nature for futher improvements. || || [[https://www.voidspace.org.uk/python/mock.html| mock]] || mock testing || Michael Foord aka [[https://www.voidspace.org.uk/python/weblog/index.shtml| Fuzzyman]] || Provides "action -> assertion" mocking patter, instead of standard "record -> replay" pattern || || [[https://pmock.sourceforge.net/| pMock]] || mock testing || Graham Carlyle || Inspired by the Java [[https://www.jmock.org/| jMock]] library, pMock makes the writing of unit tests using mock object techniques easier. Development of pmock has long since stopped and so it can be considered dead. || || [[https://blog.ianbicking.org/minimock.html| minimock]] || mock testing || [[https://blog.ianbicking.org/| Ian Bicking]] || Embeds mock testing constructs inside doctest tests. || || [[https://oakwinter.com/code/svnmock/| svnmock]] || mock testing || [[https://oakwinter.com/code/| Collin Winter]] || enables easier testing of Python programs that make use of [[https://subversion.tigris.org/| Subversion's]] Python bindings || || [[https://labix.org/mocker| Mocker]] || mock testing || [[https://blog.labix.org/| Gustavo Niemeyer]] || Graceful platform for test doubles in Python (mocks, stubs, fakes, and dummies). Well-documented and fairly feature-complete. || || [[https://www.reahl.org/project?name=stubble| Stubble]] || stub testing || [[https://www.reahl.org/| Iwan Vosloo]] || Stubble allows you to write arbitrary classes for use as stubs instead of read classes while testing. Stubble lets you link a stub class loosely to the real class which it is a stub for. This information is then used to ensure that tests will break if there is a discrepancy between the interface supported by your stub class and that of the real class it stands in for. || || [[https://code.google.com/p/pymox/| Mox]] || mock testing || smiddlek, dglasser || Mox is based on EasyMock, a Java mock object framework. Mox will make mock objects for you, so you don't have to create your own! It mocks the public/protected interfaces of Python objects. You set up your mock objects expected behavior using a domain specific language (DSL), which makes it easy to use, understand, and refactor! || || [[https://github.com/gfxmonk/mocktest/tree/master| MockTest]] || mock testing || Tim Cuthbertson (gfxmonk) || Mocktest allows you to mock / stub objects and make expectations about the methods you expect to be called as well as the arguments they should be called with. Expectations are very readable and expressive, and checked automatically. Any stubbed methods are reverted after each test case. Still under development, so subject to change || || [[https://farmdev.com/projects/fudge/| Fudge]] || mock and stub testing || [[https://farmdev.com/| Kumar McMillan]] || A module for using fake objects (mocks, stubs, etc) to test real ones. Uses a declrative syntax like jMock whereby you set up expectations for how an object should be used. An error will raise if an expectation is not met. || || [[https://code.google.com/p/mockito/wiki/MockitoForPython| Mockito for Python]] || mock and stub testing || [[https://monkeyisland.pl/| Szczepan Faber]] || A port of the [[https://code.google.com/p/mockito/| Mockito]] mocking framework to Python. (Technically speaking, Mockito is a Test Spy framework.) || || [[https://www.texttest.org/index.php?page=capturemock| CaptureMock]] || mock testing || Geoff Bache || True record-replay approach to mocking. Requires no coding, just telling it which modules/attributes you want to mock. Then stores the behaviour in an external file, which can be used to test the code without those modules installed. || |
|
Line 59: | Line 62: |
According to Wikipedia, [[https://en.wikipedia.org/wiki/Fuzz_testing|"fuzz testing" (or "fuzzing")]] is a software testing technique whose basic idea is to attach the inputs of a program to a source of random data ("fuzz"). If the program fails (for example, by crashing, or by failing built-in code assertions), then there are defects to correct. The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior. ||'''Tool''' ||'''Author''' ||'''Claim to fame''' || ||[[https://jester.sourceforge.net/|Pester]] ||Ivan Moore ||Tests your tests by mutating source code and finding tests that don't fail! || ||[[https://peachfuzz.sourceforge.net/|Peach Fuzzer Framework]] ||Michael Eddington ||Peach can fuzz just about anything from .NET, COM/ActiveX, SQL, shared libraries/DLL's, network applications, web, you name it. || ||[[https://antiparser.sourceforge.net/|antiparser]] ||dmckinney ||The purpose of antiparser is to provide an API that can be used to model network protocols and file formats by their composite data types. Once a model has been created, the antiparser has various methods for creating random sets of data that deviates in ways that will ideally trigger software bugs or security vulnerabilities. || ||[[https://sourceforge.net/projects/taof|Taof (The Art Of Fuzzing)]] ||rodrigomarcos ||Taof is a GUI cross-platform Python generic network protocol fuzzer. It has been designed for minimizing set-up time during fuzzing sessions and it is specially useful for fast testing of proprietary or undocumented protocols. || ||[[https://fusil.hachoir.org/trac|Fusil (Fusil the fuzzer)]] ||[[https://www.haypocalc.com/wiki/Victor_Stinner|Victor Stinner]] ||It helps to start process with a prepared environment (limit memory, environment variables, redirect stdout, etc.), start network client or server, and create mangled files. Fusil has many probes to detect program crash: watch process exit code, watch process stdout and syslog for text patterns (eg. "segmentation fault"), watch session duration, watch cpu usage (process and system load), etc. || |
|
Line 60: | Line 70: |
According to Wikipedia, [[https://en.wikipedia.org/wiki/Fuzz_testing| "fuzz testing" (or "fuzzing")]] is a software testing technique whose basic idea is to attach the inputs of a program to a source of random data ("fuzz"). If the program fails (for example, by crashing, or by failing built-in code assertions), then there are defects to correct. The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior. | |
Line 62: | Line 71: |
|| '''Tool''' || '''Author''' || '''Claim to fame''' || || [[https://jester.sourceforge.net/| Pester]] || Ivan Moore || Tests your tests by mutating source code and finding tests that don't fail! || || [[https://peachfuzz.sourceforge.net/| Peach Fuzzer Framework]] || Michael Eddington || Peach can fuzz just about anything from .NET, COM/ActiveX, SQL, shared libraries/DLL's, network applications, web, you name it. || || [[https://antiparser.sourceforge.net/| antiparser]] || dmckinney || The purpose of antiparser is to provide an API that can be used to model network protocols and file formats by their composite data types. Once a model has been created, the antiparser has various methods for creating random sets of data that deviates in ways that will ideally trigger software bugs or security vulnerabilities. || || [[https://sourceforge.net/projects/taof| Taof (The Art Of Fuzzing)]] || rodrigomarcos || Taof is a GUI cross-platform Python generic network protocol fuzzer. It has been designed for minimizing set-up time during fuzzing sessions and it is specially useful for fast testing of proprietary or undocumented protocols. || || [[https://fusil.hachoir.org/trac| Fusil (Fusil the fuzzer)]] || [[https://www.haypocalc.com/wiki/Victor_Stinner| Victor Stinner]] || It helps to start process with a prepared environment (limit memory, environment variables, redirect stdout, etc.), start network client or server, and create mangled files. Fusil has many probes to detect program crash: watch process exit code, watch process stdout and syslog for text patterns (eg. "segmentation fault"), watch session duration, watch cpu usage (process and system load), etc. || |
|
Line 70: | Line 74: |
Line 73: | Line 76: |
* '''Browser simulation''' tools: simulate browsers by implementing the HTTP request/response protocol and by parsing the resulting HTML * '''Browser automation''' tools: automate browsers by driving them for example via COM calls in the case of Internet Explorer, or XPCOM in the case of Mozilla * '''In-process''' or unit-test-type tools ([[https://bit.ly/n42I1X| courtesy of Ian Bicking]]): call an application in the same process, instead of generating an HTTP request; so an exception in the application would go all the way up to the command runner (py.test, unittest, etc). |
* '''Browser simulation''' tools: simulate browsers by implementing the HTTP request/response protocol and by parsing the resulting HTML * '''Browser automation''' tools: automate browsers by driving them for example via COM calls in the case of Internet Explorer, or XPCOM in the case of Mozilla * '''In-process''' or unit-test-type tools ([[https://bit.ly/n42I1X|courtesy of Ian Bicking]]): call an application in the same process, instead of generating an HTTP request; so an exception in the application would go all the way up to the command runner (py.test, unittest, etc). ||'''Tool''' ||'''Category''' ||'''Author''' ||'''Part of''' ||'''Claim to fame''' || ||[[https://twill.idyll.org/|twill]] ||Browser simulation & In-process ||[[https://www.advogato.org/person/titus/|Titus Brown]] || ||offers simple commands for navigating Web pages, posting forms and asserting conditions; can be used as shell script or Python module; can be used for [[https://www.idyll.org/~t/www-tools/twill.html#unit-testing|unit-testing your own Web app]]; stress-test functionality; port of [[https://pbp.berlios.de/|PBP]]; uses John J. Lee's [[https://wwwsearch.sf.net/|mechanize]] || ||[[https://mechanicalcat.net/tech/webunit/|webunit]] ||Browser simulation ||[[https://www.mechanicalcat.net/richard/log|Richard Jones]] || ||HTTP, HTTPS, GET, POST, basic auth all handled; control over expected status codes; uses unittest as the underlying framework || ||[[https://funkload.nuxeo.org/|FunkLoad]] ||Browser simulation ||Benoit Delbosc / [[https://www.nuxeo.com/|Nuxeo]] || ||functional/performance/load/stress testing for Web applications; easy test creation using [[https://hathawaymix.org/Software/TCPWatch/|TCPWatch]] as proxy recorder; reporting capabilities; based on [[https://mechanicalcat.net/tech/webunit/|webunit]] || ||[[https://cheeseshop.python.org/pypi?:action=display&name=zope.testbrowser|zope.testbrowser]] ||Browser simulation ||[[https://www.benjiyork.com/|Benji York]] ||[[https://www.zope.org/DevHome/Wikis/DevSite/Projects/ComponentArchitecture/FrontPage|Zope 3]] ||designed to be used in doctests that mirror user actions (see the README.txt for [[https://svn.zope.org/*checkout*/Zope3/trunk/src/zope/testbrowser/README.txt|examples]]); can also be used as standalone Web testing tool outside of Zope 3 || ||[[https://www.cherrypy.org/file/trunk/cherrypy/test/webtest.py|webtest]] ||Browser simulation ||[[https://www.aminus.org/blogs/index.php/fumanchu|Robert Brewer]] ||[[https://www.cherrypy.org/|CherryPy]] ||extensions to unittest for web frameworks; uses https://docs.python.domainunion.de/lib/module-httplib.html httplib] || ||[[https://pamie.sourceforge.net/|PAMIE]] ||Browser automation ||Robert Marchetti || ||automates Internet Explorer by manipulating IE's Document Object Model via COM || ||[[https://kb.mozillazine.org/PyXPCOM|PyXPCOM]] ||Browser automation ||[[https://starship.python.net/crew/mhammond/|Mark Hammond]] || ||provides Python XPCOM bindings for automating Mozilla browsers || ||[[https://pythonpaste.org/testing-applications.html|paste.test.fixture]] ||In-process ||[[https://blog.ianbicking.org/|Ian Bicking]] ||[[https://pythonpaste.org/|Paste]] ||lets you test your [[https://python.domainunion.de/peps/pep-0333.html|WSGI]] applications without a server; similar in feel to zope.testbrowser || ||[[https://simon.bofh.ms/cgi-bin/trac-django-projects.cgi/wiki/DjangoTesting|DjangoTesting]] ||In-process ||[[https://hugo.muensterland.org/|Georg Bauer]] ||[[https://simon.bofh.ms/cgi-bin/trac-django-projects.cgi/wiki/DjangoStuff|DjangoStuff]] ||very simple and small testing framework for [[https://www.djangoproject.com/|Django]] applications, based on the ideas of the [[https://www.rubyonrails.org/|Ruby on Rails]] testing framework; fully based on unittest, so you don't need anything beside Django and Python to make use of it || ||[[https://ibofobi.dk/blog/archive/2005/11/django-doctest/|ibofobi.utils.test]] ||In-process ||[[https://ibofobi.dk/blog/|Sune Kirkeby]] || ||testing framwework for [[https://www.djangoproject.com/|Django]] applications; built on top of doctest instead of unittest; fixtures are written in YAML not Python code; implemented simple request/response tests on top of [[https://www.crummy.com/software/BeautifulSoup/|Beautiful Soup]] || ||[[https://code.google.com/p/wsgi-intercept/|wsgi-intercept]] ||In-process ||[[https://code.google.com/u/kumar.mcmillan/|Kumar McMillan]] || ||This library lets you intercept calls to any specific host/port combination and redirect them into a WSGI application || ||[[https://www.getwindmill.com/|windmill]] ||Browser Automation ||[[https://www.getwindmill.com/|Windmill Community]] || ||Cross-Platform and Cross-Browser web automation tool, supports Firefox, Safari, Chrome and IE on Mac, Linux and Windows. Written in Python, test authoring libraries in Python and JavaScript. Active community, #windmill on irc.freenode.org || ||[[https://pypi.python.domainunion.de/pypi/selenium|Selenium]] ||Browser Automation ||[[https://seleniumhq.org|Selenium Community]] || ||Cross-Platform and Cross-Browser web automation tool, supports Firefox, Safari, Chrome and IE on Mac, Linux and Windows. Written in Java with Python bindings. Active community, #selenium on irc.freenode.org [[https://readthedocs.org/docs/selenium-python/en/latest/|Documentation]],[[https://selenium.googlecode.com/svn/trunk/docs/api/py/api.html|API]] || ||[[https://testutils.org/sst|SST]] ||Browser Automation ||Canonical Online Services Team || ||SST (selenium-simple-test) is a web test framework that uses Python to generate functional browser-based tests || |
Line 78: | Line 97: |
|| '''Tool''' || '''Category''' || '''Author''' || '''Part of''' || '''Claim to fame''' || || [[https://twill.idyll.org/| twill]] || Browser simulation & In-process || [[https://www.advogato.org/person/titus/| Titus Brown]] || || offers simple commands for navigating Web pages, posting forms and asserting conditions; can be used as shell script or Python module; can be used for [[https://www.idyll.org/%7Et/www-tools/twill.html#unit-testing| unit-testing your own Web app]]; stress-test functionality; port of [[https://pbp.berlios.de/| PBP]]; uses John J. Lee's [[https://wwwsearch.sf.net/| mechanize]] || || [[https://mechanicalcat.net/tech/webunit/| webunit]] || Browser simulation || [[https://www.mechanicalcat.net/richard/log| Richard Jones]] || || HTTP, HTTPS, GET, POST, basic auth all handled; control over expected status codes; uses unittest as the underlying framework || || [[https://funkload.nuxeo.org/| FunkLoad]] || Browser simulation || Benoit Delbosc / [[https://www.nuxeo.com/| Nuxeo]] || || functional/performance/load/stress testing for Web applications; easy test creation using [[https://hathawaymix.org/Software/TCPWatch/| TCPWatch]] as proxy recorder; reporting capabilities; based on [[https://mechanicalcat.net/tech/webunit/| webunit]] || || [[https://cheeseshop.python.org/pypi?:action=display&name=zope.testbrowser| zope.testbrowser]] || Browser simulation || [[https://www.benjiyork.com/| Benji York]] || [[https://www.zope.org/DevHome/Wikis/DevSite/Projects/ComponentArchitecture/FrontPage| Zope 3]] || designed to be used in doctests that mirror user actions (see the README.txt for [[https://svn.zope.org/*checkout*/Zope3/trunk/src/zope/testbrowser/README.txt| examples]]); can also be used as standalone Web testing tool outside of Zope 3 || || [[https://www.cherrypy.org/file/trunk/cherrypy/test/webtest.py| webtest]] || Browser simulation || [[https://www.aminus.org/blogs/index.php/fumanchu| Robert Brewer]] || [[https://www.cherrypy.org/| CherryPy]] || extensions to unittest for web frameworks; uses https://docs.python.domainunion.de/lib/module-httplib.html httplib] || || [[https://pamie.sourceforge.net/| PAMIE]] || Browser automation || Robert Marchetti || || automates Internet Explorer by manipulating IE's Document Object Model via COM || || [[https://kb.mozillazine.org/PyXPCOM| PyXPCOM]] || Browser automation || [[https://starship.python.net/crew/mhammond/| Mark Hammond]] || || provides Python XPCOM bindings for automating Mozilla browsers || || [[https://pythonpaste.org/testing-applications.html| paste.test.fixture]] || In-process || [[https://blog.ianbicking.org/| Ian Bicking]] || [[https://pythonpaste.org/| Paste]] || lets you test your [[https://python.domainunion.de/peps/pep-0333.html| WSGI]] applications without a server; similar in feel to zope.testbrowser || || [[https://simon.bofh.ms/cgi-bin/trac-django-projects.cgi/wiki/DjangoTesting| DjangoTesting]] || In-process || [[https://hugo.muensterland.org/| Georg Bauer]] || [[https://simon.bofh.ms/cgi-bin/trac-django-projects.cgi/wiki/DjangoStuff| DjangoStuff]] || very simple and small testing framework for [[https://www.djangoproject.com/| Django]] applications, based on the ideas of the [[https://www.rubyonrails.org/| Ruby on Rails]] testing framework; fully based on unittest, so you don't need anything beside Django and Python to make use of it || || [[https://ibofobi.dk/blog/archive/2005/11/django-doctest/| ibofobi.utils.test]] || In-process || [[https://ibofobi.dk/blog/| Sune Kirkeby]] || || testing framwework for [[https://www.djangoproject.com/| Django]] applications; built on top of doctest instead of unittest; fixtures are written in YAML not Python code; implemented simple request/response tests on top of [[https://www.crummy.com/software/BeautifulSoup/| Beautiful Soup]] || || [[https://code.google.com/p/wsgi-intercept/| wsgi-intercept]] || In-process || [[https://code.google.com/u/kumar.mcmillan/| Kumar McMillan]] || || This library lets you intercept calls to any specific host/port combination and redirect them into a WSGI application || || [[https://www.getwindmill.com/| windmill]] || Browser Automation || [[https://www.getwindmill.com/| Windmill Community]] || || Cross-Platform and Cross-Browser web automation tool, supports Firefox, Safari, Chrome and IE on Mac, Linux and Windows. Written in Python, test authoring libraries in Python and JavaScript. Active community, #windmill on irc.freenode.org || || [[https://pypi.python.domainunion.de/pypi/selenium|Selenium]] || Browser Automation || [[https://seleniumhq.org| Selenium Community]] || || Cross-Platform and Cross-Browser web automation tool, supports Firefox, Safari, Chrome and IE on Mac, Linux and Windows. Written in Java with Python bindings. Active community, #selenium on irc.freenode.org [[https://readthedocs.org/docs/selenium-python/en/latest/|Documentation]]|| |
== Acceptance/Business Logic Testing Tools == ||'''Tool''' ||'''Author''' ||'''Claim to fame''' || ||[[https://pypi.python.domainunion.de/pypi/behave|behave]] ||Benno Rice and Richard Jones ||A Pythonic tool for aiding Behaviour-Driven Development supporting tests written in the Gherkin language (Cucumber). || ||[[https://fitnesse.org/FitServers.PythonFit|PyFIT]] ||John Roth ||port of [[https://fit.c2.com/|FIT]]; supports both FIT and [[https://fitnesse.org/|FitNesse]]; acceptance tests for business logic written as HTML or Wiki tables || ||[[https://texttest.org/|TextTest]] ||Geoff Bache ||works by comparing plain text logged by programs with a previous 'gold standard' version of that text; the tool itself is written in Python but it can be used to test programs written in any language; comes with extensive self tests which serve as examples of how to use it. Plugins for testing GUIs (see PyUseCase) || ||[[https://lettuce.it/|Lettuce]] ||Gabriel Falcão ||port of [[Cucumber|https://cukes.info/]] supporting acceptance tests in Cucumber format, including tabular feature files and JUnit xml output. || ||[[https://svn.colorstudy.com/FitLoader/trunk/|FitLoader]] ||Ian Bicking ||A (rather alpha-ish) library for loading tests from Excel or CSV files; not really a framework, but useful for acceptance tests written by non-programmers || ||[[https://robotframework.org/|Robot Framework]] ||[[https://groups.google.com/group/robotframework-devel|Pekka Klärck]] ||Robot Framework is a keyword-driven test automation framework for acceptance level testing and acceptance test-driven development (ATDD). It has an easy-to-use tabular syntax for creating test cases and its testing capabilities can be extended by test libraries implemented either with Python or Java (requires Jython). Users can also create new keywords from existing ones using the same simple syntax that is used for creating test cases. || |
Line 93: | Line 106: |
== Acceptance/Business Logic Testing Tools == || '''Tool''' || '''Author''' || '''Claim to fame''' || || [[https://fitnesse.org/FitServers.PythonFit| PyFIT]] || John Roth || port of [[https://fit.c2.com/| FIT]]; supports both FIT and [[https://fitnesse.org/| FitNesse]]; acceptance tests for business logic written as HTML or Wiki tables || || [[https://texttest.org/| TextTest]] || Geoff Bache || works by comparing plain text logged by programs with a previous 'gold standard' version of that text; the tool itself is written in Python but it can be used to test programs written in any language; comes with extensive self tests which serve as examples of how to use it. Plugins for testing GUIs (see PyUseCase)|| || [[https://lettuce.it/| Lettuce]] || Gabriel Falcão || port of [[Cucumber| https://cukes.info/]] supporting acceptance tests in Cucumber format, including tabular feature files and JUnit xml output. || || [[https://svn.colorstudy.com/FitLoader/trunk/| FitLoader]] || Ian Bicking || A (rather alpha-ish) library for loading tests from Excel or CSV files; not really a framework, but useful for acceptance tests written by non-programmers || || [[https://robotframework.org/| Robot Framework]] || [[https://groups.google.com/group/robotframework-devel| Pekka Klärck]] || Robot Framework is a keyword-driven test automation framework for acceptance level testing and acceptance test-driven development (ATDD). It has an easy-to-use tabular syntax for creating test cases and its testing capabilities can be extended by test libraries implemented either with Python or Java (requires Jython). Users can also create new keywords from existing ones using the same simple syntax that is used for creating test cases. || |
|
Line 103: | Line 108: |
The following tools were being actively developed and maintained when this page was last edited, and have usable documentation. ||'''Tool''' ||'''Author''' ||'''Claim to fame''' || ||[[https://ldtp.freedesktop.org/wiki/|ldtp]] ||[[https://ldtp.freedesktop.org/wiki/TeamMembers|team members]] ||Uses the X11 accessability framework (AT-SPI) to drive applications so works well with the gnome desktop on Unixes. Has extensive tests for the evolution groupware client. || ||[[https://sourceforge.net/projects/pywinauto/|pywinauto]] ||Mark McMahon ||Simple Windows (NT/2K/XP) GUI automation with Python. There are tests included for Localization testing but there is no limitation to this. Most of the code at the moment is for recovering information from Windows windows and performing actions on those controls. The idea is to have high level methods for standard controls rather then rely on Sending keystrokes to the applications. || ||[[https://pyatom.com/|ATOMac]] ||Team members ||OS X Cocoa accessibility based automation library for Mac || ||[[https://www.texttest.org/index.php?page=ui_testing|PyUseCase]] ||Geoff Bache ||Domain-language based UI testing framework with a recorder. Generates plain-text descriptions (ASCII art) of what the GUI looks like during the test, intended to be used in conjunction with TextTest (see above). Mechanism for being able to record synchronisation points. Currently has mature support for PyGTK, beta status support for SWT/Eclipse RCP and Tkinter, and an early prototype for wxPython. Swing support is being developed. || |
|
Line 104: | Line 115: |
The following tools were being actively developed and maintained when this page was last edited, and have usable documentation. || '''Tool''' || '''Author''' || '''Claim to fame''' || || [[https://ldtp.freedesktop.org/wiki/| ldtp]] || [[https://ldtp.freedesktop.org/wiki/TeamMembers| team members]] || Uses the X11 accessability framework (AT-SPI) to drive applications so works well with the gnome desktop on Unixes. Has extensive tests for the evolution groupware client. || || [[https://sourceforge.net/projects/pywinauto/| pywinauto]] || Mark McMahon || Simple Windows (NT/2K/XP) GUI automation with Python. There are tests included for Localization testing but there is no limitation to this. Most of the code at the moment is for recovering information from Windows windows and performing actions on those controls. The idea is to have high level methods for standard controls rather then rely on Sending keystrokes to the applications. || || [[https://pyatom.com/ | ATOMac]] || Team members || OS X Cocoa accessibility based automation library for Mac || || [[https://www.texttest.org/index.php?page=ui_testing| PyUseCase]] || Geoff Bache || Domain-language based UI testing framework with a recorder. Generates plain-text descriptions (ASCII art) of what the GUI looks like during the test, intended to be used in conjunction with TextTest (see above). Mechanism for being able to record synchronisation points. Currently has mature support for PyGTK, beta status support for SWT/Eclipse RCP and Tkinter, and an early prototype for wxPython. Swing support is being developed. || |
|
Line 112: | Line 119: |
|| '''Tool''' || '''Last Activity''' || ''' Docs ''' || '''Author''' || '''Claim to fame''' || || [[https://fedorahosted.org/dogtail/| dogtail]] || 2009 || Good || [[https://people.redhat.com/zcerza/| Zack Cerza]] || Created by Redhat engineers on linux. Uses the X11 accessability framework (AT-SPI) to drive applications so works well with the gnome desktop on Unixes. Has [[https://people.redhat.com/zcerza/dogtail/media.html| flash movies]] || || [[https://www.tizmoi.net/watsup/intro.html| WATSUP]] || 2005 || Good || Dr Tim Couper || Windows Application Test System Using Python - another Windows GUI automation tool. || || [[https://gintas.pov.lt/guitest/| guitest]] || 2005 || Limited || [[https://gintasm.blogspot.com/| Gintautas Miliauskas]] || Python helper library for testing Python GUI applications, with [[https://www.pygtk.org/| pyGTK support]] being the most mature || || [[https://sourceforge.net/project/showfiles.php?group_id=65529| pyAA]] || 2005 || Limited || [[https://www.cs.unc.edu/%7Eparente/| Peter Parente]] || pyAA is an object oriented Python wrapper around the client-side functionality in the Microsoft Active Accessibility (MSAA) library. MSAA is a library for the Windows platform that allows client applications inspect, control, and monitor events and controls in graphical user interfaces (GUIs) and server applications to expose runtime information about their user interfaces. See the [[https://www.cs.unc.edu/%7Eparente/tech/tr09.shtml| User interface automation with pyAA]] tutorial for more info. || || [[https://sourceforge.net/projects/pyguiunit/| pyGUIUnit]] || 2004 || No || [[https://pydev.blogspot.com/| Fabio Zadrozny]] || aims to be a gui unittesting library for python; initially provided solely for [[https://www.riverbankcomputing.co.uk/pyqt/| PyQt]], but it may be extended in the future || || [[https://www.brunningonline.net/simon/blog/archives/winGuiAuto.py.html| winGuiAuto]] || 2003 || No || Simon Brunning || Low-level library for Windows GUI automation used by PAMIE and WATSUP. || |
||'''Tool''' ||'''Last Activity''' ||'''Docs''' ||'''Author''' ||'''Claim to fame''' || ||[[https://fedorahosted.org/dogtail/|dogtail]] ||2009 ||Good ||[[https://people.redhat.com/zcerza/|Zack Cerza]] ||Created by Redhat engineers on linux. Uses the X11 accessability framework (AT-SPI) to drive applications so works well with the gnome desktop on Unixes. Has [[https://people.redhat.com/zcerza/dogtail/media.html|flash movies]] || ||[[https://www.tizmoi.net/watsup/intro.html|WATSUP]] ||2005 ||Good ||Dr Tim Couper ||Windows Application Test System Using Python - another Windows GUI automation tool. || ||[[https://gintas.pov.lt/guitest/|guitest]] ||2005 ||Limited ||[[https://gintasm.blogspot.com/|Gintautas Miliauskas]] ||Python helper library for testing Python GUI applications, with [[https://www.pygtk.org/|pyGTK support]] being the most mature || ||[[https://sourceforge.net/project/showfiles.php?group_id=65529|pyAA]] ||2005 ||Limited ||[[https://www.cs.unc.edu/~parente/|Peter Parente]] ||pyAA is an object oriented Python wrapper around the client-side functionality in the Microsoft Active Accessibility (MSAA) library. MSAA is a library for the Windows platform that allows client applications inspect, control, and monitor events and controls in graphical user interfaces (GUIs) and server applications to expose runtime information about their user interfaces. See the [[https://www.cs.unc.edu/~parente/tech/tr09.shtml|User interface automation with pyAA]] tutorial for more info. || ||[[https://sourceforge.net/projects/pyguiunit/|pyGUIUnit]] ||2004 ||No ||[[https://pydev.blogspot.com/|Fabio Zadrozny]] ||aims to be a gui unittesting library for python; initially provided solely for [[https://www.riverbankcomputing.co.uk/pyqt/|PyQt]], but it may be extended in the future || ||[[https://www.brunningonline.net/simon/blog/archives/winGuiAuto.py.html|winGuiAuto]] ||2003 ||No ||Simon Brunning ||Low-level library for Windows GUI automation used by PAMIE and WATSUP. || |
Line 122: | Line 131: |
||'''Tool''' ||'''Author''' ||'''Claim to fame''' || ||[[https://pychecker.sourceforge.net/|PyChecker]] ||[[https://sourceforge.net/users/ericnewton/|Eric Newton]] and [[https://nnorwitz.blogspot.com/|Neal Norwitz]] ||finds problems that are typically caught by a compiler for less dynamic languages; imports each module before checking it || ||[[https://www.logilab.org/project/pylint|Pylint]] ||Sylvain Thénault / [[https://www.logilab.org/categories/python|Logilab]] ||includes [[https://pychecker.sourceforge.net/|PyChecker]] checks, plus more features, like checking line-code's length, checking if variable names are well-formed according to your coding standard, or checking if declared interfaces are truly implemented || ||[[https://divmod.org/trac/wiki/DivmodPyflakes|Pyflakes]] ||Phil Frost / [[https://divmod.org/trac|Divmod]] ||similar to [[https://pychecker.sourceforge.net/|PyChecker]]; focused on identifying common errors quickly without executing Python code; its primary advantage over [[https://pychecker.sourceforge.net/|PyChecker]] is that it is fast: it runs on most large projects in only a few seconds || ||[[https://clonedigger.sourceforge.net/|Clone Digger]] ||Peter Bulychev ||Clone Digger aims to detect similar code in Python and Java programs. The synonyms for the term `similar code` are `clone` and `duplicate code`. || ||[[https://pypi.python.domainunion.de/pypi/pep8/|pep8]] ||Johann C. Rocholl ||pep8 is a tool to check your Python code against some of the style conventions in PEP 8. || |
|
Line 123: | Line 138: |
|| '''Tool''' || '''Author''' || '''Claim to fame''' || || [[https://pychecker.sourceforge.net/| PyChecker]] || [[https://sourceforge.net/users/ericnewton/| Eric Newton]] and [[https://nnorwitz.blogspot.com/| Neal Norwitz]] || finds problems that are typically caught by a compiler for less dynamic languages; imports each module before checking it || || [[https://www.logilab.org/project/pylint| Pylint]] || Sylvain Thénault / [[https://www.logilab.org/categories/python| Logilab]] || includes [[https://pychecker.sourceforge.net/| PyChecker]] checks, plus more features, like checking line-code's length, checking if variable names are well-formed according to your coding standard, or checking if declared interfaces are truly implemented || || [[https://divmod.org/trac/wiki/DivmodPyflakes| Pyflakes]] || Phil Frost / [[https://divmod.org/trac| Divmod]] || similar to [[https://pychecker.sourceforge.net/| PyChecker]]; focused on identifying common errors quickly without executing Python code; its primary advantage over [[https://pychecker.sourceforge.net/| PyChecker]] is that it is fast: it runs on most large projects in only a few seconds || || [[https://clonedigger.sourceforge.net/| Clone Digger]] || Peter Bulychev || Clone Digger aims to detect similar code in Python and Java programs. The synonyms for the term `similar code` are `clone` and `duplicate code`. || || [[https://pypi.python.domainunion.de/pypi/pep8/| pep8]] || Johann C. Rocholl || pep8 is a tool to check your Python code against some of the style conventions in PEP 8. || |
|
Line 131: | Line 140: |
||'''Tool''' ||'''Author''' ||'''Claim to fame''' || ||[[https://www.nedbatchelder.com/code/modules/coverage.html|coverage]] ||[[https://www.nedbatchelder.com/blog/index.html|Ned Batchelder]] ||measures code coverage during Python execution; uses the code analysis tools and tracing hooks provided in the Python standard library to determine which lines are executable, and which have been executed || ||[[https://darcs.idyll.org/~t/projects/figleaf/README.html|figleaf]] ||[[https://ivory.idyll.org/blog/|Titus Brown]] ||figleaf is a Python code coverage analysis tool, built somewhat on the model of Ned Batchelder's fantastic coverage module. The goals of figleaf are to be a minimal replacement of 'coverage.py' that supports more configurable coverage gathering and reporting; figleaf is useful for situations where you are recording code coverage in multiple execution runs and/or want to tweak the reporting output || ||[[https://cheeseshop.python.org/pypi/trace2html|trace2html]] ||Olivier Grisel ||HTML test coverage reporting tool with white and blacklisting support || ||[[https://www.fiber-space.de/EasyExtend/doc/coverage/coverage.html|coverage langlet]] ||[[https://www.fiber-space.de/|Kay Schluehr]] ||The coverage langlet weaves monitoring commands, so called ''sensors'', into source code during global source transformation. When a statement is covered the weaved sensor responds. The coverage langlet is part of [[https://www.fiber-space.de/EasyExtend/doc/EE.html|EasyExtend]] || ||[[https://dev.nullcube.com/|pry]] ||[[https://www.nullcube.com/|Aldo Cortesi]] ||Elegant unit testing framework with built-in coverage analysis, profiling, micro-benchmarking and a powerful command-line interface. || |
|
Line 132: | Line 147: |
|| '''Tool''' || '''Author''' || '''Claim to fame''' || || [[https://www.nedbatchelder.com/code/modules/coverage.html| coverage]] || [[https://www.nedbatchelder.com/blog/index.html| Ned Batchelder]] || measures code coverage during Python execution; uses the code analysis tools and tracing hooks provided in the Python standard library to determine which lines are executable, and which have been executed || || [[https://darcs.idyll.org/%7Et/projects/figleaf/README.html| figleaf]] || [[https://ivory.idyll.org/blog/| Titus Brown]] || figleaf is a Python code coverage analysis tool, built somewhat on the model of Ned Batchelder's fantastic coverage module. The goals of figleaf are to be a minimal replacement of 'coverage.py' that supports more configurable coverage gathering and reporting; figleaf is useful for situations where you are recording code coverage in multiple execution runs and/or want to tweak the reporting output || || [[https://cheeseshop.python.org/pypi/trace2html| trace2html]] || Olivier Grisel || HTML test coverage reporting tool with white and blacklisting support || || [[https://www.fiber-space.de/EasyExtend/doc/coverage/coverage.html| coverage langlet]] || [[https://www.fiber-space.de/| Kay Schluehr]] || The coverage langlet weaves monitoring commands, so called ''sensors'', into source code during global source transformation. When a statement is covered the weaved sensor responds. The coverage langlet is part of [[https://www.fiber-space.de/EasyExtend/doc/EE.html| EasyExtend]] || || [[https://dev.nullcube.com/| pry]] || [[https://www.nullcube.com/| Aldo Cortesi]] || Elegant unit testing framework with built-in coverage analysis, profiling, micro-benchmarking and a powerful command-line interface. || |
|
Line 140: | Line 149: |
Although not properly a part of testing tools, continuous integration tools are nevertheless an important addition to a tester's arsenal. ||'''Tool''' ||'''Author''' ||'''Claim to fame''' || ||[[https://buildbot.sourceforge.net/|buildbot]] ||[[https://www.lothar.com/warner.html|Brian Warner]] ||buildbot is a system to automate the compile/test cycle required by most software projects to validate code changes. By automatically rebuilding and testing the tree each time something has changed, build problems are pinpointed quickly, before other developers are inconvenienced by the failure. || ||[[https://bitten.cmlenz.net/|Bitten]] ||[[https://cmlenz.net/|Christopher Lenz]] ||Bitten is a Python-based framework for collecting various software metrics via continuous integration. It builds on [[https://projects.edgewall.com/trac|Trac]] to provide an integrated web-based user interface. || ||[[https://cheeseshop.python.org/pypi/svnchecker/|SVNChecker]] ||Heinrich Wendel of [[https://www.dlr.de/sc/|German Aerospace Center]] ||SVNChecker is a framework for Subversion pre-commit hooks in order to implement checks of the to be commited files before they are commited. For example, you can check for the code style or unit tests. The output of the checks can be send by mail or be written into a file or simply print to the console. || ||[[https://pypi.python.domainunion.de/pypi/apycot|apycot]] ||[[https://www.logilab.fr/|Logilab]] ||an Automated Pythonic Code Tester: designed to run tests on a code repository on a daily basis. It comes with a set of predefined test, essentially for python packages, and a set of predefined reports to display execution results. However, it has been designed to be higly extensible, so you could write your own test or report using the Python language || ||[[https://github.com/ctb/pony-build|pony-build]] ||[[https://ivory.idyll.org/blog/|Titus Brown]] ||pony-build is a simple continuous integration package that lets you run a server to display client build results. It consists of two components, a server (which is run in some central & accessible location), and one or more clients (which must be able to contact the server via HTTP). Philosophy statement: good development tools for Python should be easy to install, easy to hack, and not overly constraining. Two out of three ain't bad ;). || |
|
Line 141: | Line 157: |
Although not properly a part of testing tools, continuous integration tools are nevertheless an important addition to a tester's arsenal. | |
Line 143: | Line 158: |
|| '''Tool''' || '''Author''' || '''Claim to fame''' || || [[https://buildbot.sourceforge.net/| buildbot]] || [[https://www.lothar.com/warner.html| Brian Warner]] || buildbot is a system to automate the compile/test cycle required by most software projects to validate code changes. By automatically rebuilding and testing the tree each time something has changed, build problems are pinpointed quickly, before other developers are inconvenienced by the failure. || || [[https://bitten.cmlenz.net/| Bitten]] || [[https://cmlenz.net/| Christopher Lenz]] || Bitten is a Python-based framework for collecting various software metrics via continuous integration. It builds on [[https://projects.edgewall.com/trac| Trac]] to provide an integrated web-based user interface. || || [[https://cheeseshop.python.org/pypi/svnchecker/| SVNChecker]] || Heinrich Wendel of [[https://www.dlr.de/sc/| German Aerospace Center]] || SVNChecker is a framework for Subversion pre-commit hooks in order to implement checks of the to be commited files before they are commited. For example, you can check for the code style or unit tests. The output of the checks can be send by mail or be written into a file or simply print to the console. || || [[https://www.logilab.org/project/apycot| apycot]] || [[https://www.logilab.fr/| Logilab]] || an Automated Pythonic Code Tester: designed to run tests on a code repository on a daily basis. It comes with a set of predefined test, essentially for python packages, and a set of predefined reports to display execution results. However, it has been designed to be higly extensible, so you could write your own test or report using the Python language || || [[https://github.com/ctb/pony-build| pony-build]] || [[https://ivory.idyll.org/blog/| Titus Brown]] || pony-build is a simple continuous integration package that lets you run a server to display client build results. It consists of two components, a server (which is run in some central & accessible location), and one or more clients (which must be able to contact the server via HTTP). Philosophy statement: good development tools for Python should be easy to install, easy to hack, and not overly constraining. Two out of three ain't bad ;). || |
|
Line 151: | Line 161: |
Tools that run tests automatically on file changes. Provides continuous feedback during development before continuous integration tools act on commits. ||'''Tool''' ||'''Author''' ||'''Claim to fame''' || ||[[https://pypi.python.domainunion.de/pypi/nosier/|nosier]] ||Meme Dough ||Monitors paths and upon detecting changes runs the specified command. The command may be any test runner. Uses Linux inotify so it is fast with no disk churn. || ||[[https://pypi.python.domainunion.de/pypi/nosy/|nosy]] ||Doug Latornell ||Run the nose test discovery and execution tool whenever a source file is changed. || ||[[https://pypi.python.domainunion.de/pypi/Nosyd/|nosyd]] ||Jeff Winkler & Jerome Lacoste ||A _minimalist_ personal command line friendly CI server. Automatically runs your build whenever one of the monitored files of the monitored projects has changed. || ||[[https://pypi.python.domainunion.de/pypi/PyZen/|PyZen]] ||Noah Kantrowitz ||Continuous testing for paranoid developers. || |
|
Line 152: | Line 168: |
Tools that run tests automatically on file changes. Provides continuous feedback during development before continuous integration tools act on commits. | |
Line 154: | Line 169: |
|| '''Tool''' || '''Author''' || '''Claim to fame''' || || [[https://pypi.python.domainunion.de/pypi/nosier/| nosier]] || Meme Dough || Monitors paths and upon detecting changes runs the specified command. The command may be any test runner. Uses Linux inotify so it is fast with no disk churn. || || [[https://pypi.python.domainunion.de/pypi/nosy/| nosy]] || Doug Latornell || Run the nose test discovery and execution tool whenever a source file is changed. || || [[https://pypi.python.domainunion.de/pypi/Nosyd/| nosyd]] || Jeff Winkler & Jerome Lacoste || A _minimalist_ personal command line friendly CI server. Automatically runs your build whenever one of the monitored files of the monitored projects has changed. || || [[https://pypi.python.domainunion.de/pypi/PyZen/| PyZen]] || Noah Kantrowitz || Continuous testing for paranoid developers. || |
|
Line 161: | Line 172: |
||'''Tool''' ||'''Author''' ||'''Part of''' ||'''Claim to fame''' || ||[[https://code.google.com/p/fixture/|fixture]] ||[[https://farmdev.com/|Kumar McMillan]] || ||module for loading and referencing test data || ||[[https://www.djangoproject.com/documentation/testing/#fixtures|Django Fixtures]] ||Russell Keith-Magee ||[[https://www.djangoproject.com/|django]] ||A test case for a database-backed website isn't much use if there isn't any data in the database. To make it easy to put test data into the database, Django provides a fixtures framework. || ||[[https://www.simplistix.co.uk/software/python/testfixtures|testfixtures]] ||Chris Withers || ||A collection of helpers and mock objects for unit tests and doc tests || |
|
Line 162: | Line 177: |
|| '''Tool''' || '''Author''' || '''Part of''' || '''Claim to fame''' || || [[https://code.google.com/p/fixture/| fixture]] || [[https://farmdev.com/| Kumar McMillan]] || || module for loading and referencing test data || || [[https://www.djangoproject.com/documentation/testing/#fixtures| Django Fixtures]] || Russell Keith-Magee || [[https://www.djangoproject.com/| django]] || A test case for a database-backed website isn't much use if there isn't any data in the database. To make it easy to put test data into the database, Django provides a fixtures framework. || |
|
Line 167: | Line 179: |
|| '''Tool''' || '''Author''' || '''Part of''' || '''Claim to fame''' || || [[https://cthedot.de/retest/| retest]] || [[https://cthedot.de/blog/| Christof Hoeke]] || || enables tests of Python regular expressions in a web browser; it uses SimpleHTTPServer and AJAX || || [[https://pyreb.nongnu.org/| pyreb]] || [[https://cowo.yoda2000.net/| Giuseppe "Cowo" Corbelli]] || || a wxPython GUI to the re module || || [[https://kodos.sourceforge.net/| kodos ]] || [[https://www.phil-schwartz.com/| Phil Schwartz]] || || a QT (KDE) Regular Expression Debugger || || [[https://svn.pythonpaste.org/Paste/trunk/paste/fixture.py| paste TestFileEnvironment]] || [[https://blog.ianbicking.org/| Ian Bicking]] || [[https://pythonpaste.org/| Paste]] || A simple environment for testing command-line applications, running commands and seeing what files they write to || || [[https://guppy-pe.sourceforge.net/#Heapy| Heapy]] || [[https://sncs.se/| Sverker Nilsson]] || [[https://guppy-pe.sourceforge.net/| Guppy-PE]] || supports profiling, debugging and optimization regarding memory related issues in Python programs || || [[https://pysizer.8325.org/| PySizer]] || Nick Smallbone || || a memory usage profiler for Python code || || [[https://launchpad.net/meliae| Meliae]] || [[https://launchpad.net/~jameinel| John A Meinel]] || || Memory profiling of Python processes, memory dumps can be viewed in [[https://www.vrplumber.com/programming/runsnakerun/| RunSnakerun]] || || [[https://sourceforge.net/projects/pymetrics/| PyMetrics]] || Reginald B. Charney || || Generates metrics (e.g. McCabe, LoC, %comments, etc.) for Python code. || || [[https://journyx.com/curt/complex/| complexity]] || Curt Finch || || Analyzes cyclomatic complexity of Python code (written in Perl) || || [[https://www.qmtest.com/| qmtest]] || [[https://codesourcery.com/| CodeSourcery]] || || test and automation framework, in python || || [[https://www.fiber-space.de/EasyExtend/doc/consoletest/consoletest.html| consoletest]] || [[https://www.fiber-space.de/| Kay Schluehr]] || [[https://www.fiber-space.de/EasyExtend/doc/EE.html| EasyExtend]] || Records interactive sessions and extracts test cases when they get replayed || || [[https://engineering.meta-comm.com/allpairs.aspx| AllPairs]] || [[https://engineering.meta-comm.com/allpairs.aspx| MetaCommunications]] || || Test combinations generator (in python) that allows to create set of tests using 'pairwise combinations' method, which reduces a number of combinations of variables into a lesser set which covers most situations. See https://www.pairwise.org/ for more info on this functional testing technique. || || [[https://staff.washington.edu/jon/pymodel/www/| PyModel]] || [[https://staff.washington.edu/jon/| Jon Jacky]] || || Model-based testing framework where the models are written in Python. [[https://staff.washington.edu/jon/pymodel/www/| PyModel]] supports offline and on-the-fly testing. It uses composition for scenario control. Coverage can be guided by a programmable strategy. || |
||'''Tool''' ||'''Author''' ||'''Part of''' ||'''Claim to fame''' || ||[[https://cthedot.de/retest/|retest]] ||[[https://cthedot.de/blog/|Christof Hoeke]] || ||enables tests of Python regular expressions in a web browser; it uses SimpleHTTPServer and AJAX || ||[[https://pyreb.nongnu.org/|pyreb]] ||[[https://cowo.yoda2000.net/|Giuseppe "Cowo" Corbelli]] || ||a wxPython GUI to the re module || ||[[https://kodos.sourceforge.net/|kodos]] ||[[https://www.phil-schwartz.com/|Phil Schwartz]] || ||a QT (KDE) Regular Expression Debugger || ||[[https://svn.pythonpaste.org/Paste/trunk/paste/fixture.py|paste TestFileEnvironment]] ||[[https://blog.ianbicking.org/|Ian Bicking]] ||[[https://pythonpaste.org/|Paste]] ||A simple environment for testing command-line applications, running commands and seeing what files they write to || ||[[https://guppy-pe.sourceforge.net/#Heapy|Heapy]] ||[[https://sncs.se/|Sverker Nilsson]] ||[[https://guppy-pe.sourceforge.net/|Guppy-PE]] ||supports profiling, debugging and optimization regarding memory related issues in Python programs || ||[[https://pysizer.8325.org/|PySizer]] ||Nick Smallbone || ||a memory usage profiler for Python code || ||[[https://launchpad.net/meliae|Meliae]] ||[[https://launchpad.net/~jameinel|John A Meinel]] || ||Memory profiling of Python processes, memory dumps can be viewed in [[https://www.vrplumber.com/programming/runsnakerun/|RunSnakerun]] || ||[[https://sourceforge.net/projects/pymetrics/|PyMetrics]] ||Reginald B. Charney || ||Generates metrics (e.g. McCabe, LoC, %comments, etc.) for Python code. || ||[[https://journyx.com/curt/complex/|complexity]] ||Curt Finch || ||Analyzes cyclomatic complexity of Python code (written in Perl) || ||[[https://www.qmtest.com/|qmtest]] ||[[https://codesourcery.com/|CodeSourcery]] || ||test and automation framework, in python || ||[[https://www.fiber-space.de/EasyExtend/doc/consoletest/consoletest.html|consoletest]] ||[[https://www.fiber-space.de/|Kay Schluehr]] ||[[https://www.fiber-space.de/EasyExtend/doc/EE.html|EasyExtend]] ||Records interactive sessions and extracts test cases when they get replayed || ||[[https://engineering.meta-comm.com/allpairs.aspx|AllPairs]] ||[[https://engineering.meta-comm.com/allpairs.aspx|MetaCommunications]] || ||Test combinations generator (in python) that allows to create set of tests using 'pairwise combinations' method, which reduces a number of combinations of variables into a lesser set which covers most situations. See https://www.pairwise.org/ for more info on this functional testing technique. || ||[[https://staff.washington.edu/jon/pymodel/www/|PyModel]] ||[[https://staff.washington.edu/jon/|Jon Jacky]] || ||Model-based testing framework where the models are written in Python. [[https://staff.washington.edu/jon/pymodel/www/|PyModel]] supports offline and on-the-fly testing. It uses composition for scenario control. Coverage can be guided by a programmable strategy. || |
Contents
Join the Testing In Python (TIP) mailing list for Python testing tools discussions!
This wiki page is originated from PyCheeseCake and it was originally created by Grig Gheorghiu
Unit Testing Tools
Tool |
Category |
Author |
Part of |
Claim to fame |
unit testing |
first unit test framework to be included in Python standard library; easy to use by people familiar with the xUnit frameworks; strong support for test organization and reuse via test suites |
|||
unit testing |
copy and paste output from shell session; Agile Documentation: unit tests themselves can serve as documentation when combined with epydoc; also see Django's approach |
|||
unit testing |
no API!;automatic collection of tests; simple asserts; strong support for test fixture/state management via setup/teardown hooks; strong debugging support via customized traceback |
|||
unittest extensions |
|
unit test framework, used most notably by TurboGears and Pylons; provides an alternate test discovery and running process for unittest, one that is intended to mimic the behavior of py.test as much as is reasonably possible without resorting to too much magic. More friendly with unittest.TestCase-based tests than py.test. There are also many plugins available. |
||
unittest extensions |
|
unit test framework, provides Enhanced test fixture setup, Split test suites into buckets for easy parallelization, PEP8 naming conventions & Fancy color test runner with lots of logging / reporting option. |
||
unittest extensions |
Extension of unittest to support writing asynchronous unit tests using Deferreds and new result types ('skip' and 'todo'). Includes a command-line program that does test discovery and integrates with doctest and coverage. |
|||
unittest extensions |
|
Transparently adds support for running unittest test cases/suites in a separate process : prevents system wide changes by a test destabilising the test runner. It also allows reporting from tests in another process into the unittest framework, giving a single integrated test environment. |
||
unittest extensions |
|
Provides a mechanism for managing 'resources' - expensive bits of infrastructure - that are needed by multiple tests. Resources are constructed and free on demand, but with an optional TestSuite?, the test run order is optimised to reduce the number of resource constructions and releases needed. Compatible with unittest. |
||
unittest extensions |
|
Useful extensions to unittest derived from custom extensions by projects such as Twisted and Bazaar. |
||
unit testing |
Sancho 2.1 runs tests, and provides output for tests that fail; Sancho 2.1 does not count tests passed or failed; targets projects that do not maintain failing tests |
|||
unit testing |
Zope3 community |
|
Powerful test runner that includes support for post-mortem debugging of test failures. Also includes profiling and coverage reporting. This is a standalone package that has no dependencies on Zope and works just fine with projects that don't use Zope. |
|
unit testing |
|
Elegant unit testing framework with built-in coverage analysis, profiling, micro-benchmarking and a powerful command-line interface. |
||
unit testing |
|
Tool that will automatically, or semi-automatically, generate unit tests for legacy systems written in Python. |
||
unittest extensions |
logilab-common |
Gives more power to standard unittest. More assert* methods; support for module level setup/teardown; skip test feature... |
||
tests runner |
logilab-common |
Tests finder / runner. Selectivly run tests; Stop on first failure; Run pdb on failed tests; Colorized reports; Run tests with coverage / profile enabled... |
||
unittest extensions |
PyOOP package (distributed separately too) |
An object oriented interface to retrieve unittest test cases out of doctests. Hides initialization from doctests by allowing setUp and tearDown for each interactive example. Allows control over all the options provided by doctest. Specialized classes allow selective test discovery across a package hierarchy. |
The following tools are not currently being developed or maintained as far as we can see. They are here for completeness, with last activity date and an indication of what documentation there is. If you know better, please edit.
Tool |
Last Activity |
Category |
Author |
Claim to fame |
2009 |
unittest extensions |
unittest enhancements; test filtering via regex/glob patterns; reporting in XML/HTML; colorized output; runs pdb on failing tests; run in parallel in threads/processes; verbose asserts; report failures immediately; and a little more; |
||
2009 |
performance-based unit testing |
port of JUnitPerf; transparently adds performance testing capabilities to existing unitttest-based test suites |
||
2008 |
specification-based unit testing |
like the unittest module, except that test methods may take arguments; you declare each argument with a default value which names a test-data generator and the peckcheck module will peck at your test methods with a bunch of generated values |
||
2008 |
unit testing |
A manly test runner; command-line and curses(3) interfaces; the iPod of test runners. (More seriously, makes it easier to browse and inspect your test failures) |
||
2004 |
unit testing |
Easy-to-use (PyQt) GUI framework and application for use with the Python unit testing framework. It can be used to conveniently execute unit tests and suites, and then display the results in a useful fashion. |
Mock Testing Tools
See also here for a side-by-side syntax comparison between some of the more popular tools in this space.
Tool |
Category |
Author |
Claim to fame |
mocks, stubs, spy, and dummies |
Gustavo Rezende |
Elegant test doubles framework in Python (mocks, stubs, spy, and dummies) |
|
mock testing |
Python Mock enables the easy creation of mock objects that can be used to emulate the behaviour of any class that the code under test depends on. You can set up expectations about the calls that are made to the mock object, and examine the history of calls made. This makes it easier to unit test classes in isolation. Download it here. |
||
mock testing |
PyMock is based on the Java easymock package. It uses a recording and replay model rather than using a specification language. Easymock lives up to its name compared to other mocking packages. PyMock takes advantage of python's dynamic nature for futher improvements. |
||
mock testing |
Michael Foord aka Fuzzyman |
Provides "action -> assertion" mocking patter, instead of standard "record -> replay" pattern |
|
mock testing |
Graham Carlyle |
Inspired by the Java jMock library, pMock makes the writing of unit tests using mock object techniques easier. Development of pmock has long since stopped and so it can be considered dead. |
|
mock testing |
Embeds mock testing constructs inside doctest tests. |
||
mock testing |
enables easier testing of Python programs that make use of Subversion's Python bindings |
||
mock testing |
Graceful platform for test doubles in Python (mocks, stubs, fakes, and dummies). Well-documented and fairly feature-complete. |
||
stub testing |
Stubble allows you to write arbitrary classes for use as stubs instead of read classes while testing. Stubble lets you link a stub class loosely to the real class which it is a stub for. This information is then used to ensure that tests will break if there is a discrepancy between the interface supported by your stub class and that of the real class it stands in for. |
||
mock testing |
smiddlek, dglasser |
Mox is based on EasyMock, a Java mock object framework. Mox will make mock objects for you, so you don't have to create your own! It mocks the public/protected interfaces of Python objects. You set up your mock objects expected behavior using a domain specific language (DSL), which makes it easy to use, understand, and refactor! |
|
mock testing |
Tim Cuthbertson (gfxmonk) |
Mocktest allows you to mock / stub objects and make expectations about the methods you expect to be called as well as the arguments they should be called with. Expectations are very readable and expressive, and checked automatically. Any stubbed methods are reverted after each test case. Still under development, so subject to change |
|
mock and stub testing |
A module for using fake objects (mocks, stubs, etc) to test real ones. Uses a declrative syntax like jMock whereby you set up expectations for how an object should be used. An error will raise if an expectation is not met. |
||
mock and stub testing |
A port of the Mockito mocking framework to Python. (Technically speaking, Mockito is a Test Spy framework.) |
||
mock testing |
Geoff Bache |
True record-replay approach to mocking. Requires no coding, just telling it which modules/attributes you want to mock. Then stores the behaviour in an external file, which can be used to test the code without those modules installed. |
|
mock/stub/spy testing and fake objects |
Port of the popular Ruby mocking library to Python. Includes automatic integration with most popular test runners. |
||
easy and powerful stubs, spies and mocks |
Free and restricted doubles using hamcrest matchers for all assertions. It provides a wrapper for the pyDoubles framework. |
Fuzz Testing Tools
According to Wikipedia, "fuzz testing" (or "fuzzing") is a software testing technique whose basic idea is to attach the inputs of a program to a source of random data ("fuzz"). If the program fails (for example, by crashing, or by failing built-in code assertions), then there are defects to correct. The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior.
Tool |
Author |
Claim to fame |
Ivan Moore |
Tests your tests by mutating source code and finding tests that don't fail! |
|
Michael Eddington |
Peach can fuzz just about anything from .NET, COM/ActiveX, SQL, shared libraries/DLL's, network applications, web, you name it. |
|
dmckinney |
The purpose of antiparser is to provide an API that can be used to model network protocols and file formats by their composite data types. Once a model has been created, the antiparser has various methods for creating random sets of data that deviates in ways that will ideally trigger software bugs or security vulnerabilities. |
|
rodrigomarcos |
Taof is a GUI cross-platform Python generic network protocol fuzzer. It has been designed for minimizing set-up time during fuzzing sessions and it is specially useful for fast testing of proprietary or undocumented protocols. |
|
It helps to start process with a prepared environment (limit memory, environment variables, redirect stdout, etc.), start network client or server, and create mangled files. Fusil has many probes to detect program crash: watch process exit code, watch process stdout and syslog for text patterns (eg. "segmentation fault"), watch session duration, watch cpu usage (process and system load), etc. |
Web Testing Tools
First, let's define some categories of Web testing tools:
Browser simulation tools: simulate browsers by implementing the HTTP request/response protocol and by parsing the resulting HTML
Browser automation tools: automate browsers by driving them for example via COM calls in the case of Internet Explorer, or XPCOM in the case of Mozilla
In-process or unit-test-type tools (courtesy of Ian Bicking): call an application in the same process, instead of generating an HTTP request; so an exception in the application would go all the way up to the command runner (py.test, unittest, etc).
Tool |
Category |
Author |
Part of |
Claim to fame |
Browser simulation & In-process |
|
offers simple commands for navigating Web pages, posting forms and asserting conditions; can be used as shell script or Python module; can be used for unit-testing your own Web app; stress-test functionality; port of PBP; uses John J. Lee's mechanize |
||
Browser simulation |
|
HTTP, HTTPS, GET, POST, basic auth all handled; control over expected status codes; uses unittest as the underlying framework |
||
Browser simulation |
Benoit Delbosc / Nuxeo |
|
functional/performance/load/stress testing for Web applications; easy test creation using TCPWatch as proxy recorder; reporting capabilities; based on webunit |
|
Browser simulation |
designed to be used in doctests that mirror user actions (see the README.txt for examples); can also be used as standalone Web testing tool outside of Zope 3 |
|||
Browser simulation |
extensions to unittest for web frameworks; uses https://docs.python.domainunion.de/lib/module-httplib.html httplib] |
|||
Browser automation |
Robert Marchetti |
|
automates Internet Explorer by manipulating IE's Document Object Model via COM |
|
Browser automation |
|
provides Python XPCOM bindings for automating Mozilla browsers |
||
In-process |
lets you test your WSGI applications without a server; similar in feel to zope.testbrowser |
|||
In-process |
very simple and small testing framework for Django applications, based on the ideas of the Ruby on Rails testing framework; fully based on unittest, so you don't need anything beside Django and Python to make use of it |
|||
In-process |
|
testing framwework for Django applications; built on top of doctest instead of unittest; fixtures are written in YAML not Python code; implemented simple request/response tests on top of Beautiful Soup |
||
In-process |
|
This library lets you intercept calls to any specific host/port combination and redirect them into a WSGI application |
||
Browser Automation |
|
Cross-Platform and Cross-Browser web automation tool, supports Firefox, Safari, Chrome and IE on Mac, Linux and Windows. Written in Python, test authoring libraries in Python and JavaScript. Active community, #windmill on irc.freenode.org |
||
Browser Automation |
|
Cross-Platform and Cross-Browser web automation tool, supports Firefox, Safari, Chrome and IE on Mac, Linux and Windows. Written in Java with Python bindings. Active community, #selenium on irc.freenode.org Documentation,API |
||
Browser Automation |
Canonical Online Services Team |
|
SST (selenium-simple-test) is a web test framework that uses Python to generate functional browser-based tests |
Acceptance/Business Logic Testing Tools
Tool |
Author |
Claim to fame |
Benno Rice and Richard Jones |
A Pythonic tool for aiding Behaviour-Driven Development supporting tests written in the Gherkin language (Cucumber). |
|
John Roth |
port of FIT; supports both FIT and FitNesse; acceptance tests for business logic written as HTML or Wiki tables |
|
Geoff Bache |
works by comparing plain text logged by programs with a previous 'gold standard' version of that text; the tool itself is written in Python but it can be used to test programs written in any language; comes with extensive self tests which serve as examples of how to use it. Plugins for testing GUIs (see PyUseCase) |
|
Gabriel Falcão |
port of https://cukes.info/ supporting acceptance tests in Cucumber format, including tabular feature files and JUnit xml output. |
|
Ian Bicking |
A (rather alpha-ish) library for loading tests from Excel or CSV files; not really a framework, but useful for acceptance tests written by non-programmers |
|
Robot Framework is a keyword-driven test automation framework for acceptance level testing and acceptance test-driven development (ATDD). It has an easy-to-use tabular syntax for creating test cases and its testing capabilities can be extended by test libraries implemented either with Python or Java (requires Jython). Users can also create new keywords from existing ones using the same simple syntax that is used for creating test cases. |
GUI Testing Tools
The following tools were being actively developed and maintained when this page was last edited, and have usable documentation.
Tool |
Author |
Claim to fame |
Uses the X11 accessability framework (AT-SPI) to drive applications so works well with the gnome desktop on Unixes. Has extensive tests for the evolution groupware client. |
||
Mark McMahon |
Simple Windows (NT/2K/XP) GUI automation with Python. There are tests included for Localization testing but there is no limitation to this. Most of the code at the moment is for recovering information from Windows windows and performing actions on those controls. The idea is to have high level methods for standard controls rather then rely on Sending keystrokes to the applications. |
|
Team members |
OS X Cocoa accessibility based automation library for Mac |
|
Geoff Bache |
Domain-language based UI testing framework with a recorder. Generates plain-text descriptions (ASCII art) of what the GUI looks like during the test, intended to be used in conjunction with TextTest (see above). Mechanism for being able to record synchronisation points. Currently has mature support for PyGTK, beta status support for SWT/Eclipse RCP and Tkinter, and an early prototype for wxPython. Swing support is being developed. |
The following tools are not currently being developed or maintained as far as we can see. They are here for completeness, with last activity date and an indication of what documentation there is. If you know better, please edit.
Tool |
Last Activity |
Docs |
Author |
Claim to fame |
2009 |
Good |
Created by Redhat engineers on linux. Uses the X11 accessability framework (AT-SPI) to drive applications so works well with the gnome desktop on Unixes. Has flash movies |
||
2005 |
Good |
Dr Tim Couper |
Windows Application Test System Using Python - another Windows GUI automation tool. |
|
2005 |
Limited |
Python helper library for testing Python GUI applications, with pyGTK support being the most mature |
||
2005 |
Limited |
pyAA is an object oriented Python wrapper around the client-side functionality in the Microsoft Active Accessibility (MSAA) library. MSAA is a library for the Windows platform that allows client applications inspect, control, and monitor events and controls in graphical user interfaces (GUIs) and server applications to expose runtime information about their user interfaces. See the User interface automation with pyAA tutorial for more info. |
||
2004 |
No |
aims to be a gui unittesting library for python; initially provided solely for PyQt, but it may be extended in the future |
||
2003 |
No |
Simon Brunning |
Low-level library for Windows GUI automation used by PAMIE and WATSUP. |
Source Code Checking Tools
Tool |
Author |
Claim to fame |
finds problems that are typically caught by a compiler for less dynamic languages; imports each module before checking it |
||
Sylvain Thénault / Logilab |
includes PyChecker checks, plus more features, like checking line-code's length, checking if variable names are well-formed according to your coding standard, or checking if declared interfaces are truly implemented |
|
Phil Frost / Divmod |
similar to PyChecker; focused on identifying common errors quickly without executing Python code; its primary advantage over PyChecker is that it is fast: it runs on most large projects in only a few seconds |
|
Peter Bulychev |
Clone Digger aims to detect similar code in Python and Java programs. The synonyms for the term similar code are clone and duplicate code. |
|
Johann C. Rocholl |
pep8 is a tool to check your Python code against some of the style conventions in PEP 8. |
Code Coverage Tools
Tool |
Author |
Claim to fame |
measures code coverage during Python execution; uses the code analysis tools and tracing hooks provided in the Python standard library to determine which lines are executable, and which have been executed |
||
figleaf is a Python code coverage analysis tool, built somewhat on the model of Ned Batchelder's fantastic coverage module. The goals of figleaf are to be a minimal replacement of 'coverage.py' that supports more configurable coverage gathering and reporting; figleaf is useful for situations where you are recording code coverage in multiple execution runs and/or want to tweak the reporting output |
||
Olivier Grisel |
HTML test coverage reporting tool with white and blacklisting support |
|
The coverage langlet weaves monitoring commands, so called sensors, into source code during global source transformation. When a statement is covered the weaved sensor responds. The coverage langlet is part of EasyExtend |
||
Elegant unit testing framework with built-in coverage analysis, profiling, micro-benchmarking and a powerful command-line interface. |
Continuous Integration Tools
Although not properly a part of testing tools, continuous integration tools are nevertheless an important addition to a tester's arsenal.
Tool |
Author |
Claim to fame |
buildbot is a system to automate the compile/test cycle required by most software projects to validate code changes. By automatically rebuilding and testing the tree each time something has changed, build problems are pinpointed quickly, before other developers are inconvenienced by the failure. |
||
Bitten is a Python-based framework for collecting various software metrics via continuous integration. It builds on Trac to provide an integrated web-based user interface. |
||
Heinrich Wendel of German Aerospace Center |
SVNChecker is a framework for Subversion pre-commit hooks in order to implement checks of the to be commited files before they are commited. For example, you can check for the code style or unit tests. The output of the checks can be send by mail or be written into a file or simply print to the console. |
|
an Automated Pythonic Code Tester: designed to run tests on a code repository on a daily basis. It comes with a set of predefined test, essentially for python packages, and a set of predefined reports to display execution results. However, it has been designed to be higly extensible, so you could write your own test or report using the Python language |
||
pony-build is a simple continuous integration package that lets you run a server to display client build results. It consists of two components, a server (which is run in some central & accessible location), and one or more clients (which must be able to contact the server via HTTP). Philosophy statement: good development tools for Python should be easy to install, easy to hack, and not overly constraining. Two out of three ain't bad ;). |
Automatic Test Runners
Tools that run tests automatically on file changes. Provides continuous feedback during development before continuous integration tools act on commits.
Tool |
Author |
Claim to fame |
Meme Dough |
Monitors paths and upon detecting changes runs the specified command. The command may be any test runner. Uses Linux inotify so it is fast with no disk churn. |
|
Doug Latornell |
Run the nose test discovery and execution tool whenever a source file is changed. |
|
Jeff Winkler & Jerome Lacoste |
A _minimalist_ personal command line friendly CI server. Automatically runs your build whenever one of the monitored files of the monitored projects has changed. |
|
Noah Kantrowitz |
Continuous testing for paranoid developers. |
Test Fixtures
Tool |
Author |
Part of |
Claim to fame |
|
module for loading and referencing test data |
||
Russell Keith-Magee |
A test case for a database-backed website isn't much use if there isn't any data in the database. To make it easy to put test data into the database, Django provides a fixtures framework. |
||
Chris Withers |
|
A collection of helpers and mock objects for unit tests and doc tests |
Miscellaneous Python Testing Tools
Tool |
Author |
Part of |
Claim to fame |
|
enables tests of Python regular expressions in a web browser; it uses SimpleHTTPServer and AJAX |
||
|
a wxPython GUI to the re module |
||
|
a QT (KDE) Regular Expression Debugger |
||
A simple environment for testing command-line applications, running commands and seeing what files they write to |
|||
supports profiling, debugging and optimization regarding memory related issues in Python programs |
|||
Nick Smallbone |
|
a memory usage profiler for Python code |
|
|
Memory profiling of Python processes, memory dumps can be viewed in RunSnakerun |
||
Reginald B. Charney |
|
Generates metrics (e.g. McCabe, LoC, %comments, etc.) for Python code. |
|
Curt Finch |
|
Analyzes cyclomatic complexity of Python code (written in Perl) |
|
|
test and automation framework, in python |
||
Records interactive sessions and extracts test cases when they get replayed |
|||
|
Test combinations generator (in python) that allows to create set of tests using 'pairwise combinations' method, which reduces a number of combinations of variables into a lesser set which covers most situations. See https://www.pairwise.org/ for more info on this functional testing technique. |
||
|
Model-based testing framework where the models are written in Python. PyModel supports offline and on-the-fly testing. It uses composition for scenario control. Coverage can be guided by a programmable strategy. |