tox?

[Christophe Pettus]

On a Django-related project I maintain, someone's submitted a PR that includes a tox.ini file. I'll admit I've not used tox before; how standard is it for Django testing? I like the idea of being able to run tests against multiple versions in parallel, but I don't want to require a tool for testing unless it's very widely used.

--
-- Christophe Pettus
x...@thebuild.com

[Jani Tiainen]

Hi,

Tox is quite widely adopted. For example django-rest-framework uses it to run tests against various combinations of python and django.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/5D5F6545-742C-4942-A86E-76359E82B057%40thebuild.com.
For more options, visit https://groups.google.com/d/optout.

[James Schneider]

On Oct 8, 2017 3:21 PM, "Christophe Pettus" <x...@thebuild.com> wrote:

On a Django-related project I maintain, someone's submitted a PR that includes a tox.ini file.  I'll admit I've not used tox before; how standard is it for Django testing?  I like the idea of being able to run tests against multiple versions in parallel, but I don't want to require a tool for testing unless it's very widely used.

I'm not familiar with Tox or it's usage, but in general, I wouldn't make it a requirement for an end user, and possibly not even for a contributor of a PR.

IMO, a unit test should only rely on the base test framework included with Django. An extension like Tox (based on the information blurb above) should take those tests and run them in multiple environments automatically in a dedicated test environment that you manage. An end user should be able to run your tests against their specific environment without it, along with PR authors for simple bugfix patches. Code standards should be clearly published and outlined, and should include comprehensive enough information that all target environments will pass the same tests, ie requiring Py2/Py3 compatibility, PEP 8, and so on.

Larger PR's that introduce new functionality or significant code changes should be required to utilize something like Tox before being submitted/accepted, but as long as that is also clearly documented, any dev providing code at that level shouldn't have an issue complying.

OTOH, it's presumably your software, and if you like it and want everything tested to that degree before it reaches the PR stage, that's your call. Larger projects may require this to filter out the number of PR's that people file, but you also run the risk of missing out on good patches that an author didn't submit because they didn't feel like deploying and learning a new test suite.

As a rebuttal against my own argument for not requiring it, Django does ship with built-in Tox support, although I'm sure other configuration is required:

https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/#running-tests-using-tox

Just my $0.02...

-James