4 ms·
Thinking this a bit further, it would be possible to write a simple xdoctest command that would extract all code blocks from a JavaScript document and save them
by bergie 14y ago
Thinking this a bit further, it would be possible to write a simple xdoctest command that would extract all code blocks from a JavaScript document and save them in the format doctest.js supports. Then you could do stuff like:
## Capitalizing text
The `capitalize` function receives a string and returns
it in capitalized format. Example:
```javascript
print(capitalize('some words'));
// => Some Words
```
...and generate both your API docs and the runnable tests from the same file. This way you'd only need to keep one set of examples/tests up to date.
- ianb 14y agoWith doctest.js potentially the HTML docs/examples are runnable tests, and you wouldn't have to generate both (or the difference would just be whether you included doctest.js) If you could just do: ```javascript;commenttest print(capitalize('some words')); // => Some Words ``` and if javascript;commenttest got translated into <pre class="commenttest">, then you'd be good to go right now, without any special support from doctest. I believe if the element is syntax highlighted that doctest will just ignore (and wipe) that highlighting, but it depends on the details, I've never personally tried it. If you could add multiple classes you could use javascript;commenttest.hidden for setup code that you want to run as part of the tests, but doesn't add to the narrative. (There's a class that makes setup blocks compact, but I suppose I could extend it to do hidden blocks too: http://doctestjs.org/reference.html#compact http://doctestjs.org/reference.html#compact) I don't think there's an advantage for doctest to parse the Markdown directly, as opposed to parsing what is rendered. And extracting just the code also seems unnecessary, as it is helpful to see the context of any failures.