...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.
* It makes it much harder to write custom assertions and get
meaningful display on error.
Can you give an examples for cases with messages/breakings and for
custom assertions?
Regarding magic in Pytest - yeah - there is some =))
But if think deeper, inheritance and self is also magic, and Pytest just
uses its own magic (dependency injection) that is differs from OO magic =)
Actually it would be interesting to discuss cases where Pytest cant
handle (or handle with convennience) what PyUnit can and vice versa.
On 06.04.2014 21:02, 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.
* 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.
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.
--
С наилучшими пожеланиями, Андрей Пашкин.
м.т - +7 (985) 898 57 59
Skype - waves_in_fluids
e-mail - andrew.pash...@gmx.co.uk
--
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/5341952A.8000201%40gmx.co.uk.
For more options, visit https://groups.google.com/d/optout.
