Files
@ 877bcf22bf71
Branch filter:
Location: kallithea/CONTRIBUTORS - annotation
877bcf22bf71
4.9 KiB
text/plain
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 | 24c0d584ba86 e3bb18948760 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 32cdc6f70f13 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 84bb160aac6d 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 7918ed610324 e3bb18948760 7918ed610324 7918ed610324 ee2817f2cb3d 8b7294a804a0 9a6c224e1f68 8b7294a804a0 7918ed610324 7918ed610324 e3bb18948760 7918ed610324 | List of contributors to Kallithea project:
Mads Kiilerich <madski@unity3d.com> 2012-2015
Takumi IINO <trot.thunder@gmail.com> 2012-2015
Unity Technologies 2012-2015
Andrew Shadura <andrew@shadura.me> 2012 2014-2015
Aras Pranckevičius <aras@unity3d.com> 2012-2013 2015
Sean Farley <sean.michael.farley@gmail.com> 2013-2015
Christian Oyarzun <oyarzun@gmail.com> 2014-2015
Joseph Rivera <rivera.d.joseph@gmail.com> 2014-2015
Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> 2014-2015
Anatoly Bubenkov <bubenkoff@gmail.com> 2015
Andrew Bartlett <abartlet@catalyst.net.nz> 2015
Balázs Úr <urbalazs@gmail.com> 2015
Ben Finney <ben@benfinney.id.au> 2015
Branko Majic <branko@majic.rs> 2015
Daniel Hobley <danielh@unity3d.com> 2015
David Avigni <david.avigni@ankapi.com> 2015
Denis Blanchette <dblanchette@coveo.com> 2015
duanhongyi <duanhongyi@doopai.com> 2015
EriCSN Chang <ericsning@gmail.com> 2015
Étienne Gilli <etienne.gilli@gmail.com> 2015
Grzegorz Krason <grzegorz.krason@gmail.com> 2015
Jan Heylen <heyleke@gmail.com> 2015
Jiří Suchan <yed@vanyli.net> 2015
Kazunari Kobayashi <kobanari@nifty.com> 2015
Kevin Bullock <kbullock@ringworld.org> 2015
kobanari <kobanari@nifty.com> 2015
Marc Abramowitz <marc@marc-abramowitz.com> 2015
Marc Villetard <marc.villetard@gmail.com> 2015
Matthias Zilk <matthias.zilk@gmail.com> 2015
Michael Pohl <michael@mipapo.de> 2015
Michael V. DePalatis <mike@depalatis.net> 2015
Morten Skaaning <mortens@unity3d.com> 2015
Nick High <nick@silverchip.org> 2015
Niemand Jedermann <predatorix@web.de> 2015
Peter Vitt <petervitt@web.de> 2015
Robert Martinez <ntttq@inboxen.org> 2015
Robert Rauch <mail@robertrauch.de> 2015
Ronny Pfannschmidt <opensource@ronnypfannschmidt.de> 2015
Sam Jaques <sam.jaques@me.com> 2015
Søren Løvborg <sorenl@unity3d.com> 2015
Tuux <tuxa@galaxie.eu.org> 2015
Viktar Palstsiuk <vipals@gmail.com> 2015
Dominik Ruf <dominikruf@gmail.com> 2012 2014
Bradley M. Kuhn <bkuhn@sfconservancy.org> 2014
Calinou <calinou@opmbx.org> 2014
Daniel Anderson <daniel@dattrix.com> 2014
Henrik Stuart <hg@hstuart.dk> 2014
Ingo von Borstel <kallithea@planetmaker.de> 2014
Jelmer Vernooij <jelmer@samba.org> 2014
Jim Hague <jim.hague@acm.org> 2014
Matt Fellows <kallithea@matt-fellows.me.uk> 2014
Max Roman <max@choloclos.se> 2014
Michal Čihař <michal@cihar.com> 2014
Na'Tosha Bard <natosha@unity3d.com> 2014
Rasmus Selsmark <rasmuss@unity3d.com> 2014
Tim Freund <tim@freunds.net> 2014
Travis Burtrum <android@moparisthebest.com> 2014
Zoltan Gyarmati <mr.zoltan.gyarmati@gmail.com> 2014
Marcin Kuźmiński <marcin@python-works.com> 2010-2013
xpol <xpolife@gmail.com> 2012-2013
Aparkar <aparkar@icloud.com> 2013
Dennis Brakhane <brakhane@googlemail.com> 2013
Grzegorz Rożniecki <xaerxess@gmail.com> 2013
Jonathan Sternberg <jonathansternberg@gmail.com> 2013
Leonardo Carneiro <leonardo@unity3d.com> 2013
Magnus Ericmats <magnus.ericmats@gmail.com> 2013
Martin Vium <martinv@unity3d.com> 2013
Simon Lopez <simon.lopez@slopez.org> 2013
Ton Plomp <tcplomp@gmail.com> 2013
Augusto Herrmann <augusto.herrmann@planejamento.gov.br> 2011-2012
Dan Sheridan <djs@adelard.com> 2012
Dies Koper <diesk@fast.au.fujitsu.com> 2012
Erwin Kroon <e.kroon@smartmetersolutions.nl> 2012
H Waldo G <gwaldo@gmail.com> 2012
hppj <hppj@postmage.biz> 2012
Indra Talip <indra.talip@gmail.com> 2012
mikespook 2012
nansenat16 <nansenat16@null.tw> 2012
Philip Jameson <philip.j@hostdime.com> 2012
Raoul Thill <raoul.thill@gmail.com> 2012
Stefan Engel <mail@engel-stefan.de> 2012
Tony Bussieres <t.bussieres@gmail.com> 2012
Vincent Caron <vcaron@bearstech.com> 2012
Vincent Duvert <vincent@duvert.net> 2012
Vladislav Poluhin <nuklea@gmail.com> 2012
Zachary Auclair <zach101@gmail.com> 2012
Ankit Solanki <ankit.solanki@gmail.com> 2011
Dmitri Kuznetsov 2011
Jared Bunting <jared.bunting@peachjean.com> 2011
Jason Harris <jason@jasonfharris.com> 2011
Les Peabody <lpeabody@gmail.com> 2011
Liad Shani <liadff@gmail.com> 2011
Lorenzo M. Catucci <lorenzo@sancho.ccd.uniroma2.it> 2011
Matt Zuba <matt.zuba@goodwillaz.org> 2011
Nicolas VINOT <aeris@imirhil.fr> 2011
Shawn K. O'Shea <shawn@eth0.net> 2011
Thayne Harbaugh <thayne@fusionio.com> 2011
Łukasz Balcerzak <lukaszbalcerzak@gmail.com> 2010
Andrew Kesterson <andrew@aklabs.net>
cejones
David A. Sjøen <david.sjoen@westcon.no>
James Rhodes <jrhodes@redpointsoftware.com.au>
Jonas Oberschweiber <jonas.oberschweiber@d-velop.de>
larikale
RhodeCode GmbH
Sebastian Kreutzberger <sebastian@rhodecode.com>
Steve Romanow <slestak989@gmail.com>
SteveCohen
Thomas <thomas@rhodecode.com>
Thomas Waldmann <tw-public@gmx.de>
|