sáb 13 fevereiro 2016
| tags: python testing pytest
Pytest Sprint 2016
In June pytest core developers and users are gathering in Freiburg, Germany for
a sprint . This is being
funded by a indiegogo campaign , so
if you are a pytest user or your company heavily relies on pytest, please consider
making a donation!
Some topics I'm excited about and probably will work on are:
Improve pytest-xdist to use fixture-based scheduling. This is a long standing
topic, you can see more details in this
pytest-xdist issue .
Improve xUnit setup/teardown support by using internal auto-use fixtures.
This would solve some ordering issues like #517 .
Fixing some long standing bugs and review the issue tracker.
Back in 2013
I was really excited when I first discovered pytest. I wrote a post
titled pytest: best thing since sliced bread in our company blog, highlighting the features I
liked best. Our blog is not public, but I will post some of its
contents here:
assertEqual? no more. You just use plain asserts, and assertion rewrite
means that special output in failed assertions can be done, for example
by showing a context diff if a string comparison fails.
Test finding : The test runner automatically finds and runs tests just like
we expect it, including xUnit style tests.
Also, it supports using simple functions instead of having to subclass some test base class.
This was a problem back then, so we wrote our own test runner.
Code Coverage : Back then our own test runner implemented code coverage.
Parallel Support : Again our test runner implemented this. This was a major
need for us as we have thousands of tests so running them sequentially is not
an option.
skip and xfail built-in decorators.
--pastebin parameter. Very useful to share errors with others, better
than pasting a messy traceback in Skype (still used for communication to this day).
This is an underrated core plugin in my opinion. :)
Fixtures , which is one of the killer pytest feature.
The automatic dependency injection really shines in promoting code re-use
between tests.
Plugins : all features are implemented in terms of plugins,
and this is another pytest killer feature as the
plugin ecosystem is huge.
Adopting
py.test was so feature-rich that we decided to ditch our test runner. It was
argued that even if you wanted to write only xUnit-style tests and leave
more advanced features (like fixtures) alone, being able to write plain asserts
was enough reason to replace our runner.
It was only two years later that we could finally adopt py.test
for all projects. While initially there were concerns now even the initial
nay-sayers are praising py.test.
It took us this long because:
It was not a full-time thing, it was something one team member or another
(mostly me) spending some free extra time on.
We needed support for running Qt tests, so I wrote pytest-qt .
There were several tests with problems when running under xdist. This happened
because our custom runner parallized tests by file , while xdist parallizes
all tests. When xdist was brought in several tests presented concurrency
issues within tests on the same file, as they never ran in parallel before.
But the adoption is complete and we couldn't be happier with it. We are also
migrating from xUnit tests to fixture based ones as time allows.
Now
It's been two years since I became a pytest
core developer. I dedicate time to it as much as I can spare, trying to be helpful
in the issue tracker, contributing PRs and
working on meta-improvements like moving the project to GitHub,
improving the release process, documentation, etc.
Pytest was created by such intelligent and friendly people, I'm really happy to
be able to work on it and be part of the community.
comments
