Files
@ 877bcf22bf71
Branch filter:
Location: kallithea/docs/index.rst - annotation
877bcf22bf71
1.2 KiB
text/prs.fallenstein.rst
pytest migration: introduce TestControllerPytest
In order to allow tests to benefit from pytest specific functionality, like
fixtures, they can no longer derive from unittest.TestCase. What's more,
while they can derive from any user-defined class, none of the classes
involved (the test class itself nor any of the base classes) can have an
__init__ method.
Converting all tests from unittest-style to pytest-style in one commit is
not realistic. Hence, a more gradual approach is needed.
Most existing test classes derive from TestController, which in turn derives
from BaseTestCase, which derives from unittest.TestCase. Some test classes
derive directly from BaseTestCase.
Supporting both unittest-style and pytest-style from TestController directly
is not possible: pytest-style _cannot_ and unittest-style _must_ derive from
unittest.TestCase. Thus, in any case, an extra level in the class hierarchy
is needed (TestController deriving from Foo and from unittest.TestCase;
pytest-style test classes would then directly derive from Foo).
The requirement that pytest-style test classes cannot have an __init__
method anywhere in the class hierarchy imposes another restriction that
makes it difficult to support both unittest-style and pytest-style test
classes with one class. Any init code needs to be placed in another method
than __init__ and be called explicitly when the test class is initialized.
For unittest-style test classes this would naturally be done with a
setupClass method, but several test classes already use that. Thus, there
would need to be explicit 'super' calls from the test classes. This is
technically possible but not very nice.
A more transparent approach (from the existing test classes point of view),
implemented by this patch, works as follows:
- the implementation of the existing TestController class is now put under
a new class BaseTestController. To accomodate pytest, the __init__ method
is renamed init.
- contrary to the original TestController, BaseTestController does not
derive from BaseTestCase (and neither from unittest.TestCase). Instead,
the 'new' TestController derives both from BaseTestCase, which is
untouched, and from BaseTestController.
- TestController has an __init__ method that calls the base classes'
__init__ methods and the renamed 'init' method of BaseTestController.
- a new class TestControllerPytest is introduced that derives from
BaseTestController but not from BaseTestCase. It uses a pytest fixture to
automatically call the setup functionality previously provided by
BaseTestCase and also calls 'init' on BaseTestController. This means a
little code duplication but is hard to avoid.
The app setup fixture is scoped on the test method, which means that the app
is recreated for every test (unlike for the unittest-style tests where the
app is created per test class). This has the advantage of detecting current
inter-test dependencies and thus improve the health of our test suite. This
in turn is one step closer to allowing parallel test execution.
The unittest-style assert methods (assertEqual, assertIn, ...) do not exist
for pytest-style tests. To avoid having to change all existing test cases
upfront, provide transitional implementations of these methods. The
conversion of the unittest asserts to the pytest/python asserts can happen
gradually over time.
In order to allow tests to benefit from pytest specific functionality, like
fixtures, they can no longer derive from unittest.TestCase. What's more,
while they can derive from any user-defined class, none of the classes
involved (the test class itself nor any of the base classes) can have an
__init__ method.
Converting all tests from unittest-style to pytest-style in one commit is
not realistic. Hence, a more gradual approach is needed.
Most existing test classes derive from TestController, which in turn derives
from BaseTestCase, which derives from unittest.TestCase. Some test classes
derive directly from BaseTestCase.
Supporting both unittest-style and pytest-style from TestController directly
is not possible: pytest-style _cannot_ and unittest-style _must_ derive from
unittest.TestCase. Thus, in any case, an extra level in the class hierarchy
is needed (TestController deriving from Foo and from unittest.TestCase;
pytest-style test classes would then directly derive from Foo).
The requirement that pytest-style test classes cannot have an __init__
method anywhere in the class hierarchy imposes another restriction that
makes it difficult to support both unittest-style and pytest-style test
classes with one class. Any init code needs to be placed in another method
than __init__ and be called explicitly when the test class is initialized.
For unittest-style test classes this would naturally be done with a
setupClass method, but several test classes already use that. Thus, there
would need to be explicit 'super' calls from the test classes. This is
technically possible but not very nice.
A more transparent approach (from the existing test classes point of view),
implemented by this patch, works as follows:
- the implementation of the existing TestController class is now put under
a new class BaseTestController. To accomodate pytest, the __init__ method
is renamed init.
- contrary to the original TestController, BaseTestController does not
derive from BaseTestCase (and neither from unittest.TestCase). Instead,
the 'new' TestController derives both from BaseTestCase, which is
untouched, and from BaseTestController.
- TestController has an __init__ method that calls the base classes'
__init__ methods and the renamed 'init' method of BaseTestController.
- a new class TestControllerPytest is introduced that derives from
BaseTestController but not from BaseTestCase. It uses a pytest fixture to
automatically call the setup functionality previously provided by
BaseTestCase and also calls 'init' on BaseTestController. This means a
little code duplication but is hard to avoid.
The app setup fixture is scoped on the test method, which means that the app
is recreated for every test (unlike for the unittest-style tests where the
app is created per test class). This has the advantage of detecting current
inter-test dependencies and thus improve the health of our test suite. This
in turn is one step closer to allowing parallel test execution.
The unittest-style assert methods (assertEqual, assertIn, ...) do not exist
for pytest-style tests. To avoid having to change all existing test cases
upfront, provide transitional implementations of these methods. The
conversion of the unittest asserts to the pytest/python asserts can happen
gradually over time.
5f481e4e888b 5f481e4e888b 22a3fa3c4254 beb4cbf30d00 22a3fa3c4254 22a3fa3c4254 03bbd33bc084 bdd1ddd05b7c 03bbd33bc084 03bbd33bc084 5f481e4e888b 03bbd33bc084 03bbd33bc084 03bbd33bc084 5f481e4e888b 5f481e4e888b 5f481e4e888b 5f481e4e888b 154becd92f40 5f481e4e888b 64b1a2320bcb d95ea48af67b e69d34136be5 3389f272ece1 57caeb60c52b 8b8edfc25856 bb35ad076e2f bb35ad076e2f bb35ad076e2f bb35ad076e2f bb35ad076e2f bbd499c7b55e 601282d36c06 aa17c7a1b8a5 bbd499c7b55e beb4cbf30d00 22a3fa3c4254 beb4cbf30d00 beb4cbf30d00 beb4cbf30d00 beb4cbf30d00 2079e864ce51 beb4cbf30d00 af371e206ec5 4d076981a7b1 aa90719e8520 4d076981a7b1 22a3fa3c4254 bb35ad076e2f bb35ad076e2f bb35ad076e2f 8b8edfc25856 bb35ad076e2f 42a87338035a 5f481e4e888b bb35ad076e2f bb35ad076e2f bb35ad076e2f 9da24750f563 bb35ad076e2f b43a121f3137 b43a121f3137 8b8edfc25856 bb35ad076e2f 5f481e4e888b ed2fb6e84a02 5f481e4e888b 5f481e4e888b 5f481e4e888b 5f481e4e888b fbbe80e3322b a60cd29ba7e2 5f481e4e888b 5f481e4e888b 5f481e4e888b 9472a0150bf0 5f481e4e888b a60cd29ba7e2 a60cd29ba7e2 a60cd29ba7e2 8b8edfc25856 | .. _index:
#######################
Kallithea Documentation
#######################
**Readme**
.. toctree::
:maxdepth: 1
readme
**Installation**
.. toctree::
:maxdepth: 1
overview
installation
installation_win
installation_win_old
installation_iis
setup
installation_puppet
**Usage**
.. toctree::
:maxdepth: 1
usage/general
usage/vcs_support
usage/locking
usage/statistics
**Administrator's guide**
.. toctree::
:maxdepth: 1
usage/email
usage/performance
usage/backup
usage/debugging
usage/troubleshooting
**Development**
.. toctree::
:maxdepth: 1
contributing
changelog
**API**
.. toctree::
:maxdepth: 1
api/api
api/models
Other topics
************
* :ref:`genindex`
* :ref:`search`
.. _virtualenv: http://pypi.python.org/pypi/virtualenv
.. _python: http://www.python.org/
.. _django: http://www.djangoproject.com/
.. _mercurial: http://mercurial.selenic.com/
.. _bitbucket: http://bitbucket.org/
.. _subversion: http://subversion.tigris.org/
.. _git: http://git-scm.com/
.. _celery: http://celeryproject.org/
.. _Sphinx: http://sphinx.pocoo.org/
.. _vcs: http://pypi.python.org/pypi/vcs
|