[TIP] Docstrings in Test methods

Alfredo Deza alfredodeza at gmail.com
Sat Nov 5 19:21:00 PDT 2011


On Sat, Nov 5, 2011 at 2:25 PM, Gary Bernhardt <gary.bernhardt at gmail.com> wrote:
> On Sat, Nov 5, 2011 at 8:50 AM, Alfredo Deza <alfredodeza at gmail.com> wrote:
>> What do you guys prefer and why (or why not?)
>
> The problem isn't that you need more space for the description; that's
> just the symptom. The problem is that your'e not separating the name
> of the context from the name of the expectation. Try naming your
> classes for the state of the world, and the tests for the exact thing
> that you expect to happen. Like this:
>
> class when_bar_connects_successfully:
>    def foo_is_true(self):
>        ...
>

Not sure I entirely agree with this approach, it could get very
repetitive very fast. I tend
to have test classes that I can group with a setup that makes sense
for a few tests, if I name
the classes after the state I would have to probably use inheritance
to avoid repeating setup
over and over again.


> I willfully violate PEP 8's capitalization rules in this case because
> the camel casing gets too hard to read. You can teach Nose to run
> tests like these with a sufficiently advanced -m. Expecter Gadget's
> runtests.py does this, though it's a weaker form than the example
> above. It's here:
> https://github.com/garybernhardt/expecter/blob/master/runtests.py

Yes, violating PEP8 is OK if it will improve readability. I like the
idea of having
specific, granular signatures though.

I think there is a clear misunderstanding as to what should be a
correct approach because there is a reason
why unittest decided it was *awesome* to mangle the signature and slap
the docstring.

Maybe this is not a problem of descriptive method signatures but a
test runner one (granted, py.test doesn't
fall into this category).
>
> --
> Gary
> http://destroyallsoftware.com
>



More information about the testing-in-python mailing list