Hi Chris, Just a couple notes to set the record straight:
On Sunday, April 6, 2014 1:02:18 PM UTC-4, Chris Wilson wrote: > > Hi Andrew, > > I'm not a Django core contributor but just a user and occasional patcher. > I submit some comments on this proposal in the hope that they will be > useful. > > On Sun, 6 Apr 2014, Andrew Pashkin wrote: > > > Some Pytest advocacy: > > 1) Pytest has convenient tests collection options - you can just specify > folder to run all tests in it. It is also possible to > > filter tests by regex, and select specific ones. > > I do use pytest and it has a lot of good points. Running all tests in a > directory or a specific file is one of them, as is the better test > selection logic. > > > class MyTestCase(TestCase): > > def test_something(self): > > expected_content = ... > > response = self.client(...) > > self.assertEqual(expected_content, response.content) > > > > Pytest: > > > > def test_something(client): > > expected_content = ... > > response = self.client(...) > > assert expected_content == response.content > > But this is not one of them, at least not for me. I strongly dislike this > style of assertions: > > > Pytest style is cleaner and complies PEP8. Assertions with assert are > more readable. > > * The difference between "self.assertEquals(a, b)" and "assert a == b" is > minimal for me. > > * It hides a LOT of magic in how pytest goes back and evaluates the > assertion's arguments again if the assertion fails. Sometimes it gets > different results (if one of the tested methods has side effects) and then > the assertion message makes no sense, hides the problem, or pytest breaks. > This has not been true since pytest 2.1.0, released July 2011. Since then, pytest rewrites assertions in the AST via an import hook instead of re-evaluating assertion arguments on failure, so there are no such problems with side effects in one side of an assertion. See http://pytest.org/latest/assert.html for details. > * It makes it much harder to write custom assertions and get meaningful > display on error. > > > It is also possible to group tests, by placing them into class without > > subclassing something. > > Grouping tests with decorators allows tests to be members of multiple > suites, it's true. However this is not something that I've ever needed. > > And losing the power of inheritance to add methods to my test classes, by > not putting tests into classes, is enough to kill this style completely > for me. I write a LOT of my own assertions: > > https://github.com/aptivate/django-harness/tree/master/django_harness > > > 4) In Pytest it is possible to define setup functions for modules, > classes and specific tests. > > I can do this by adding mixins to test classes. Works fine for me, and > less magical. > > > 5) Pytest also has fixture mechanism, which allows to use additional > > resources in tests by specifying fixture names as an arguments (like > > client) - it is good alternative to using setUp's and subclassing > > something. > > We have named fixtures in Django test classes already, so I don't see that > as much of an advantage. We can't easily add fixtures in mixins at the > moment. I've not needed that so far. > Pytest fixtures are a much more general and powerful concept than Django fixtures; they allow you to write modular code to setup and teardown any type of resource that a test may need. Django's fixtures are limited to data dumps; IMO data-dump fixtures cause test maintainability problems and should usually be avoided (in favor of object factories). > > 6) pytest-xdist plugin provides parallel execution of tests. > > 7) Pytest has features for writing parametrized tests. > > > > So Pytest is kind of cool and it is easy to migrate to it. > > I don't think it's necessary or wise to rewrite the test suite to use > pytest-style assertions. But better integration of Django and Pytest, and > the ability to write tests with Pytest-style assertions if you like, would > certainly have my support (fwiw). > > Cheers, Chris. > -- > Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838 > Citylife House, Sturton Street, Cambridge, CB1 2QF, UK > > Aptivate is a not-for-profit company registered in England and Wales > with company number 04980791. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5bb9c004-9251-4fb3-9ae3-5ac8d6513142%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
