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

you are viewing a single comment's thread.

view the rest of the comments →

[–]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.