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.
2) PyUnit:
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
Pytest style is cleaner and complies PEP8. Assertions with assert are more
readable. It is also possible to group tests, by placing them into class,
without subclassing something.
4) In Pytest it is possible to define setup functions for modules, classes
and specific tests.
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.
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.
On Friday, February 28, 2014 3:42:17 AM UTC+4, Russell Keith-Magee wrote:
>
>
> On Fri, Feb 28, 2014 at 4:17 AM, Gwildor Sok <[email protected]<javascript:>
> > wrote:
>
>> Personally I'm a big fan of Py.test, simply because it's so simple and
>> Pythonic to use. Simple functions with simple assert statements. That's
>> all. For me this significantly lowers the threshold to write tests and
>> requires less effort, which in the end results in way more tests written in
>> Py.test than the testsuite Django is currently using.
>>
>
> This is an argument that I've never understood. Why is typing:
>
> class MyTestCase(TestCase):
>
> such a burden? Because once you've typed that, everything else in the
> class is "just a method". However, you also get the added benefit of test
> grouping, and if you've got common setup/teardown requirements, the class
> provides a place to put them.
>
> I know py.test has a lot of fans, but I'm seriously unconvinced by the
> "it's so easy to write tests" argument.
>
> For this proposal to be acceptable to core, it's going to need to start
> with a *comprehensive* analysis of why py.test is a better approach to
> take. Don't just assume everyone is on board.
>
> Yours,
> Russ Magee %-)
>
--
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/f1133fe6-bd1c-4641-857a-e721e26e4e23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
