On Wed, Dec 7, 2011 at 4:55 PM, Annie <anni...@gmail.com> wrote: > Hi all - > > I have some questions before I submit a ticket with a patch to change > a few things in the docs/topics/testing.txt file. One change is a typo > fix, and another is a possible change I have a question about. Since > they're both relatively minor changes to the same file (no major > rewrites required), do I submit both on one ticket (after my question > about the second change is answered here) with my patch, or do they > need to be submitted separately?
Hi Annie, If someone were committing in the testing docs, and there are two minor fixes, they're just as likely to roll them into a single commit, with the comment "Minor updates to the testing documentation"; in which case, a single ticket is probably ok. The point at which a second ticket is called for is the point at which it is likely that one of the fixes will *not* be applied. This could be due to a number of reasons: * One of the changes is large, and requires further review * The updates relate to different parts of the documentation, and aren't thematically bound (e.g., fixing usage of its/it's in multiple locations) * One of the changes is controversial or requires further discussion. In this case, I'd be happy to say both these changes could be classified as two related, uncontroversial improvements, so a single ticket is probably OK. > This example under the "Running tests" section of the page is what > confused me when I read it, so I thought I should check before I > suggested a change in case I was reading the example incorrectly. *g* > > Here's the relevant bit of the docs: > > ------------ > > And it gets even more granular than that! To run a *single* test > method inside a test case, add the name of the test method to the > label:: > > $ ./manage.py test animals.AnimalTestCase.testFluffyAnimals > > ------------ > > > In both unittest and doctest examples given above that test run > example, there is no testFluffyAnimals method. The unittest defines > testSpeaking and the doctest uses speak. I think it would be clearer > if the example read like this: > > $ ./manage.py test animals.AnimalTestCase.testSpeaking > > > Am I reading the original example correctly? Or is it just that my > brain's tired from looking at this stuff too long today? :) Looks like a good catch to me. We should certainly aim to be internally consistent, and I can't see any reason not to be in this case. > Ok, I lied, there's actually a third issue--something I noticed as I > was double checking before I sent this email: shouldn't the method be > named test_speaking, if we're supposed to follow the guidelines on the > coding style page? "Use underscores, not camelCase, for variable, > function and method names (i.e. poll.get_unique_voters(), not > poll.getUniqueVoters)." Also a good catch. If you're in the area and aiming for perfection, I'd be inclined to take a closer look at the test names, too. testSpeaking isn't an especially good test name -- something like test_animals_can_speak(), that phrases the test as an assertion would be a better example. Giving the test a docstring that will be used by the test runner verbose/error output would also be a good idea. I look forward to seeing your ticket and patch. Thanks for pitching in! Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
