<br><br><div class="gmail_quote">On Mon, Feb 27, 2012 at 3:59 PM, Michael Foord <span dir="ltr"><<a href="mailto:fuzzyman@gmail.com">fuzzyman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div class="im">On 27 February 2012 20:35, Michael Foord <span dir="ltr"><<a href="mailto:fuzzyman@gmail.com" target="_blank">fuzzyman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>Personally I think there are several fundamental problems with doctest *as a unit testing tool*. doctest is *awesome* for testing documentation examples but in particular this one:<br><br>* Every line becomes an assertion - in a unit test you typically follow the arrange -> act -> assert pattern. Only the results of the *assertion* are relevant to the test. (Obviously unexpected exceptions at any stage are relevant....). With doctest you have to take care to ensure that the exact output of *every line* of your arrange and act steps also match, even if they are irrelevant to your assertion. (The arrange and act steps will often include lines where you are creating state, and their output is irrelevant so long as they put the right things in place.)<br>


<br>The particular implementation of doctest means that there are additional, potentially resolvable problems that are also a damn nuisance in a unit testing fail:<br></div></div></blockquote><div><br></div></div><div>Jeepers, I changed direction mid-sentence there. It should have read something along the lines of:</div>

<div><br></div><div>As well as fundamental problems, the particular implementation of doctest suffers from these potentially resolvable problems:</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>The problem of being dependent on order of unorderable types (actually very difficult to solve).<br><br></div></div></blockquote></div></div></blockquote></div>I just thought of something:  isn't the obvious solution is for doctest to test the type of an expression's output and if it's in the set of unordered types {set, dict} to run sort() on it?  Then the docstring author can just put the (sorted) output of what's expected....<div>
<br></div><div>Perhaps I'm hashing a dead horse, but I really would like to see this added to the issue's tracker as a requested feature.  I may code up the patch myself, but it helps my brain to have it "on the dev stack".</div>
<div><br></div><div>mark<br><div><br></div></div>