On Sun, Oct 28, 2012 at 7:33 AM, Jan Bednařík <jan.bedna...@gmail.com>wrote:
> Hi all, > > I'm using Django for more than four years and last week I started > contributing. > > In docs about contributing I didn't find how detailed should be my testing > while I'm writing or reviewing patch? Is enough to run tests only for > patched module? Or should I run full test suite for each patch? Which > combinations of Python versions and database engines are mandatory? > > So far I was running Python 2.7 & SQLite3 for development/review testing > of module. Python 3.2 & SQLite3, Python 2.7 & PostgreSQL for patched module > and in the end Python 2.7 & SQLite3 full test suite (with selenium, etc.). > Is this workflow ok? > > Hi Jan, I've noticed your contributions on Trac this week. Thanks very much for taking the leap from user to contributor. Django wouldn't be where it was today without the efforts of people like yourself. So - how much testing is required? Enough to ensure that whatever it is you're submitting won't break when we apply the patch. Obviously, more is better, but you can apply a little discretion. If you're tweaking something in the template language, there's not much point running all the tests for the ORM. However, as a final check before you commit, it certainly wouldn't hurt to do one final run of the full test suite, just be sure. As for databases? Again, it depends a little bit on what you're testing. If you're modifying the template language, you can assume the ORM will do the right thing; just running the tests under SQLite will probably suffice. However, if your modifying the behaviour of queries, you need to run against every backend possible (that means SQLite, MySQL with MyISAM and InnoDB, PostgreSQL and Oracle). Don't worry *too* much about multiple versions of each database; there aren't *that* many inconsistencies between versions of databases, and if there is *that* will be the subject of the bug report (in which case, running the tests with different versions of the same database *will* be required). As for Python versions? At a minimum, you should be running the tests on a Python 2 version and a Python 3 version. It's generally a good idea to use the lowest supported version you can - so, Python 2.6 and 3.2 - because that's the most likely to reveal problems with accidentally using new features in the language. Ultimately, the goal is to make the best use of the development community's time. The core team are the bottleneck in the development process, because we're the only people who can commit code. That means that we need the community to make sure we waste as little of our time as possible. If we receive a patch that fails because it breaks the test suite, then that slows down the rate at which we can commit patches. So - the more testing you do to make sure that the core team doesn't get a broken patch, the better. Of course, we're not going to blame anyone if a test breaks in a weird or unexpected way. Mistakes happen -- we'd just rather they didn't :-) Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
