Finally, someone wrote a version of doctest for Ruby.
Recently I’ve been writing most of my tests using stand-alone doctest files. It’s a great way to do TDD — mostly because the cognitive load is so low. Also, I write my examples but don’t write my output, then copy the output after visually confirming it is correct. So the basic pattern is:
- Figure out what I want to do
- Figure out how I want to test it
- Automate my conditions
- Manually inspect whether the output is correct (i.e., implement and debug)
- Copy the output so that in the future the manual process is automated (doctest-mode for Emacs makes this particularly easy)
The result is a really good balance of manual and automated testing, I think giving you the benefit of both processes — the ease of manual testing, and the robustness of automated testing.
Another good thing about doctest is it doesn’t let you hide any boilerplate and setup. If it’s easy to use doctest, it’s probably easy to use the library.
There’s nothing Python-specific about doctest (e.g., doctestjs), so it’s good to see it moving to other languages. Even if the language doesn’t have a REPL, IMHO it’s worth inventing it just for this.
Automatically generated list of related posts:
- A Doctest Wishlist Lately I’ve been doing most of my testing with doctest,...
- Doctest.js & Callbacks Many years ago I wrote a fairly straight-forward port of...
- Atom Models I’ve been doing a bit more with Atom lately. First,...
Its great to see the idea of doctest spreading – every Dynamic language with a shell interface should have it!
Maybe someone should prompt those Perl 6 guys :-)
Thinking about these new versions made me add to the doctest wikipedia page a comment about not mentioning on the wiki page until they became language standards though. This in turn gave me a great way of tidying-up the wikipedia Duck Typing entry so thanks.
Yea! one less lib for me to write :)
“it doesn’t let you hide any boilerplate and setup”
The ruby implementation sucks, IMHO, since: - it force me to put a “doctest:” directive before every example - it force me to give a “test name” to my examples (hey, I’m writing a documentation, not a testcase!) - “it [effectively] doesn’t let you hide any boilerplate and setup”, which sucks for rails, since I’ll not use my code outside of this setup, and since it requires me to put some “doctest_require” directive before my examples (whereas in python doctests, I can accomplish some setup during the DocTestSuite instanciation). - as a result, it doesn’t feel natural, and sucks as a documentation
sebn: we use rubydoctest for most of the documentation for the Hobo project: http://cookbook.hobocentral.net/manual/toc. We never use the doctest: directive, never give test names, never use doctest_require and always hide our boilerplate and setup.
Bryan: ok, I probably missed something, thanks for the comment.