Ah, I see.
Well, in my experience, unittests and doctests serve two different
purposes. The former is for ensuring the correctness of the program whereas
the latter is for communicating use, very much like an example. Because, as
you say, doctests can get quite large, each doctest forces you to think
about the minimal interface to any function, and forces you to realise what
it is dependent on by what you have to do so set the function up in the
example code. Less is often better.
I typically run doctest alongside running tests, via nose that would be
something along the lines of passing --with-doctest to the command-line
interface. In addition, I tend to stick with the overall mental model of
having tests *either* as a doctest, *or* as a unittest, such that they both
don’t end up testing the same thing. Though it’s mostly about balance and
what’s the most maintainable and makes the most sense.
I would run them via sphinx, but only as a measure of ensuring that what
I’ve written is runnable, so that the documentation is correct. I would not
rely on sphinx (or any documentation) to determine the correctness of the
program, that’s backwards.
*Example*
def my_function(arg1=True):
"""A great function
Arguments:
arg1 (bool, optional): Whether or not to be great
Example:
>>> value = True
>>> my_function(value)
False
Returns:
bool: Inverse of input argument
"""
# implementation here
This for example communicates both what a function takes as input, and what
it produces as output. The same information can be found under Arguments
and Returns, but the example can be physically tested for correctness,
whereas the others are used by programs like sphinx to do HTML formatting.
In an ideal world, they would have a form of correlation such that they
couldn’t provide differing information, but such is life.
On 30 June 2016 at 06:07, Fredrik Averpil <[email protected]> wrote:
> So I’m thinking I’d probably rather run tests completely separated from
> Sphinx.
>
> Sorry, I meant to say I’d rather run tests not defined in docstrings… and
> instead define them in separate file(s), outside of my application and
> outside of docstrings/Sphinx.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python_inside_maya/CAD%3DwhWO1wGQn%3D8XhS8HypavmDP%3DeNzoxdjE%3DauD4rGWOW9vcVw%40mail.gmail.com
> <https://groups.google.com/d/msgid/python_inside_maya/CAD%3DwhWO1wGQn%3D8XhS8HypavmDP%3DeNzoxdjE%3DauD4rGWOW9vcVw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
*Marcus Ottosson*
[email protected]
--
You received this message because you are subscribed to the Google Groups
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBXZGH3tbs3VsHVYWmFyfN%2B0fMpkV3XMLXR_ZBgK6MMoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
