-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move doctests to unittests #17
Conversation
Why shouldn't these be in doctests? |
It’s fine to have example tests in the docstring but unittest is better for thorough testing, doctest is more appropriate for documenting or basic testing. The docstrings should be short and to the point, they end up in .doc. Having the unit tests in a separate file makes the main script lighter. There are also several issues with using only doctests, unittests are just more flexible and can be more atomic. |
Yes, but... This isn't a typical module that needs atomic documentation. There is commandline behavior and a single public function. The rest is all internal. I don't have anything against unittests. In this case, I put everything in doctests because it made sense to put the tests next to the code that they are evaluating. In almost all of the functions in this file the tests were the documentation. Now things like I'll think about this switch. I'm not rejecting it. I just need to think about it. |
f958b37
to
eed2e21
Compare
Alright, I decided to merge this just to keep the main file shorter. Could you resolve the conflicts and update the PR? |
OK. I'll update the PR next week. |
…"should be" in doc of handleClash1 and handleClash2
@typesupply OK, the branch has been rebased and adff343 reflect the changes made in the doctests. |
ufonormalizer -t
calls unittest instead of doctestplistlib.loads()
and.dumps()
if available (Python 3.4 deprecatedplistlib.readPlistFromBytes()
, .writePlistToBytes()` and prints warnings when used)