Contributing to Django or any large-scale open source project is usually like engaging in a discussion during philosophy class. You might think you had an original idea, but then you find mountains of past threads, forums, pull request comments, and entire third-party libraries that disect, discourage, encourage, celebrate, and abhor your idea.

It’s amazing.

One such idea I had was using pytest instead of unittest for Django’s testing framework. I initially stumbled on that idea after going through all testing framework tickets on Django a month and a half ago when I was working on my GSoC proposal. I wanted to know if there were any outstanding issues about the test runner that I should keep in mind. I did find two that were related: one about Django’s faulthandler and another about output buffering.

I also found plenty of tickets that started marked as New feature and inevitably ended in discussions as “oh but pytest already implements this, why don’t we use it?” versus “why should we add a dependency onto our project and what merits would it bring us over standard unittest?”.

No original ideas (or solutions)

I was naive enough to think to myself that after I was done with my Google Summer of Code project, I could make an original django pytest third party to solve all of those tickets. I say naive because someone already did it. After reading through their documentation and their issue tracker, it was still clear that were issues that were for better or worse unresolvable or simply too ugly to implement due to being a third-party library that had to fit its code within Django’s constraints. Examples included supporting multi-db testing, handling migrations, selenium tests, and general compatibility with Django’s test runner command line options. However, it still brings pytest to Django users and fulfills their testing needs as much as it possibly can without rewriting Django’s source code.

Shelved but not abandoned

So the idea is already out there, the question is: is there a better possible solution? I definitely think there are areas Django can refactor/rewrite to allow better reusability/extensibility for third-party testing apps like py-test. Django adopting pytest would be a massive change that would need a more gradual process.

Going through ticket chains and pull request comments like this is worth it however. Even if I didn’t resolve any of those tickets, having a good understanding of the testing framework’s limitations on itself and on expansion will help when I propose to expand it, and formalize a plan to do so. It also gave me a good understanding of what should change about the parallel test runner, but that’s for another post.