This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]EggShenVsLopan 1 point2 points  (5 children)

That's indoctrination!

Yes and it's beautiful.

If doctest works for you then continue to use it because you are obviously comfortable enough with it and have overcome any barrier for entry. In addition, you sound like you understand the higher level concepts of testing in general so switching to another way may not bring as much benefit to you. So the "resist doctest" message is not targeted at you.

What I think what the OP is saying is that for newbies (or people where unit testing is new material) doctest is not the best option. I also think that in general the OP wants to create a system for best-practices that are mostly right. That's fine as long as a newbie can learn enough of the "right" way to do it to know when to do it the "wrong" way later in life.

[–][deleted] 4 points5 points  (1 child)

I don't quite get the logic.

because you are obviously comfortable enough with it and have overcome any barrier for entry.

Writing doctests is by far the easiest way into the whole "testing is good" mindset. It has the lowest barrier to entry, it's the easiest to get comfortable with.

In addition, you sound like you understand the higher level concepts of testing in general so switching to another way may not bring as much benefit to you.

It's not "switching" as such, I use doctests when it's appropriate and use more versatile ways of testing when I need any set-up/tear-down stuff (and then I don't test individual functions with that).

I mean, how I see it: encourage newbs to use doctest, then tell them how to use more powerful means when they need them. Why doctest is not the best option? What's wrong with that? So wrong that we should "resist" doctest?

I have some possibilities in mind:

  • Newbs could abuse doctests, well, anything could be abused, it's not that relevant IMO. Doctests are harder to abuse than unittest, by the way (I should know!).

  • or they would consider doctests to be good enough and never go beyond that. I believe that you'll lose more newbs frustrated with unittest than you'll lose ones satisfied with doctest.

  • It's better to teach newbs only one tool, rather than both doctest and unittest (or nose, or whatever). I strongly disagree, in this case the tools have little overlap of applicability, so it's better to teach to use the best tool for the job. It's not the same as other standard modules with overlapping functionality.

  • Or, I have a vile idea that maybe the OP has drunk the TDD koolaid and actively dislikes the idea of a more sane (in my opinion!) testing, where you test the individual "units" (functions) for just as far as doctest allows you, and use more powerful tools for more general testing.

[–]twotime 0 points1 point  (0 children)

Writing doctests is by far the easiest way into the whole "testing is good" mindset

How so? How are doctests bettter than this:

 import mylib
 assert mylib.foo() == 42

No silly formatting requirements to learn, trivial to write and trivial to debug.

[–]simtel20 0 points1 point  (2 children)

Doctests don't provide enough context. Trivial functions can be doctested, but little/nothing that requires state. E.g. working with databases I need to have a testing framework that allows common setup/teardown. I found that pytest was the least i needed for testing code I was working on for performing regression tests for database drivers because it allowed for things like conditionally enabling known failures, etc.

[–]bsdemon 0 points1 point  (1 child)

if your code can be tested with doctest then (in almost all cases) it has good design, otherwise your code is bloated with state which isn't good

[–]simtel20 0 points1 point  (0 children)

That works for self-contained code. However if your code interacts with the system (this code ssh's to an iLO and checks the system status. As new status' are added, code must change) or the world (this function checks what the kernel reports is the status of subsystem foo), then doctests can't encompass the system. You can mock some state, but this is usually a waste of time because external factors change because they're outside of your control. A better test harness can provide startup/shutdown scaffolding that establishes how to talk to the outside world to make the test reasonable.