-</pre><h2>Defining your expectations<a name="3"></a></h2><p>Each time doctest runs a test, it's running a line of code and checking that the output is what you say it should be. It knows something is an example because it's a line in help('your_function') that starts with '&gt;&gt;'. It knows what you think the output should be by starting on the line after &gt;&gt; and looking for the next &gt;&gt;, two blank lines, or the end of the documentation.</p><p>If the output of some function will change each time you call it, for instance if it includes a random number or a stack trace, you can put <b>*</b> (three asterisks) where the changing element should be. This acts as a wildcard, and will match anything. See the example below.</p><p>Here are some examples of formatting, both ones that work and ones that don't.</p><pre class="codeinput">type <span class="string">formatting</span>

+</pre><h2>Defining your expectations<a name="3"></a></h2><p>Each time doctest runs a test, it's running a line of code and checking that the output is what you say it should be. It knows something is an example because it's a line in help('your_function') that starts with '&gt;&gt;'. It knows what you think the output should be by starting on the line after &gt;&gt; and looking for the next &gt;&gt;, two blank lines, or the end of the documentation.</p><p>If the output of some function will change each time you call it, for instance if it includes a random number or a stack trace, you can put '***' (three asterisks) where the changing element should be. This acts as a wildcard, and will match anything. See the example below.</p><p>Here are some examples of formatting, both ones that work and ones that don't.</p><pre class="codeinput">type <span class="string">formatting</span>

</pre><h2>Expecting an error<a name="4"></a></h2><p>doctest can deal with errors, a little bit. You might want this to test that your function correctly detects that it is being given invalid parameters. But if your example will emit other output BEFORE the error message, the current version can't deal with that. For more info see Issue #4 on the bitbucket site (below). Warnings are different from errors, and they work fine.</p><pre class="codeinput">type <span class="string">errors</span>

disp <span class="string">-------------</span>

% the documentation.

%

% If the output of some function will change each time you call it, for

-% instance if it includes a random number or a stack trace, you can put ***

-% (three asterisks) where the changing element should be. This acts as a

-% wildcard, and will match anything. See the example below.

+% instance if it includes a random number or a stack trace, you can put

+% '***' (three asterisks) where the changing element should be. This acts

+% as a wildcard, and will match anything. See the example below.

%

% Here are some examples of formatting, both ones that work and ones that

README.markdown

Each time doctest runs a test, it's running a line of code and checking that the output is what you say it should be. It knows something is an example because it's a line in help('your_function') that starts with '>>'. It knows what you think the output should be by starting on the line after >> and looking for the next >>, two blank lines, or the end of the documentation.

-If the output of some function will change each time you call it, for instance if it includes a random number or a stack trace, you can put ***** (three asterisks) where the changing element should be. This acts as a wildcard, and will match anything. See the example below.

+If the output of some function will change each time you call it, for instance if it includes a random number or a stack trace, you can put '***' (three asterisks) where the changing element should be. This acts as a wildcard, and will match anything. See the example below.

Here are some examples of formatting, both ones that work and ones that don't.