[Python-3000] doctests vs. unittests (was Re: pimp; restructuring the standard library)
Barry Warsaw
barry at python.org
Fri Jun 29 18:12:28 CEST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Since this has stopped being on-topic for this mailing list, so just
one last follow up from me.
On Jun 29, 2007, at 11:37 AM, Phillip J. Eby wrote:
> The question is more one of, "documentation for whom?". You can
> write separate documents for library users than for library
> extenders/developers. I don't put doctests in docstrings, but if I
> did, I'd probably only put user doctests there. As it is, I
> normally split my doctests into multiple files for different
> audiences, or under different headings in one large file.
>
> Another library I'm working on has two doctest files for users (a
> quick intro and a developer guide/reference) and a separate file
> that tests all the innards. So, there are a lot of ways to use
> doctests effectively, at least if you're doing them in text files,
> rather than in your docstrings. I've actually never put a doctest
> in a docstring; it always seems like overkill to me. (Especially
> since reST doctests can be made into nice HTML pages like the above!)
I concur with Phillip about two important points. First, I also
never put doctests in docstrings. I find them unreadable, difficult
to edit, and not conducive to a cohesive narrative. I always put my
doctests in a separate file, usually under a 'docs' directory
actually. Maybe this will make a difference for people considering
doctests as a complement to traditional unittests.
Second, I agree that you can achieve a high degree of coverage with
doctests if you stop to answer Phillip's question: "documentation for
whom?" I typically put documentation for users in a separate file
than documentation for extenders/developers, but that's just personal
taste. The important insight is that explaining how to use a library
often covers most if not all the corner cases of its use.
Lastly, an observation: I've found that using doctests has had the
surprisingly consequence of making test-driven development
enjoyable. I've found myself starting a new task by writing the
documentation first, which is a great way to design how you want the
code to work. Because the documentation is testable, you're left
with a simple matter of coding <wink> until the doctest passes.
Cheers,
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iQCVAwUBRoUvbXEjvBPtnXfVAQIodgP9H7+7LFCY+TJtCMbeZjl9Q1JHXBrZyIBj
q0aQFR82qvo/I/OUoAwLAqOQbAxyXXBMiEVuAKBQA8ETCOhmOcF/apTmizu0SWZR
b4a6XbvPiIH9DMeOWyFOEEqchfMYFyqWkp+J5fc1mmyF9wLGeQxdmUffzSy17a66
7b/GQBwajlI=
=Aamm
-----END PGP SIGNATURE-----
More information about the Python-3000
mailing list