This talk is not about API docs, but fully fleshed out, article style technical documentation like tutorials.
We never merge changes breaking our tests.
What about changes that break our documentation?
Can we test that?
Software documentation is an interesting edge-case of natural language interleaved with formal language (often code).
If you use downstream libraries and document interactions with them, you have to track this for those libraries, too.
Don’t include code in your documentation.
Sidestepping a problem isn’t much fun.
We can output the string "hello world" using the puts
Scenario: Use puts to output "hello world".
Given a file named "puts.rb" with:
puts "hello world"
This writes a Ruby file, evaluates it and tests your assumptions. It uses Gherkins description features.
Python ships a mixture of method docs and runnable code: doctest
"""Return the factorial of n, an exact integer >= 0.
>>> [factorial(n) for n in range(6)]
[1, 1, 2, 6, 24, 120]
Very nice if the scope is limited the module at hand.
When your test fits a table… Selenium:
Use selenium steps both as visual documentation and for testing.
Implemented by walkhub.
All these approches start out in with testing formats and build towards written text from there. They automatically follow the structure of the code.
Literate programming interleaves text and code. It it’s purest style, code has to marked instead of comments.
Implemented in Haskell: count.lhs
Count Count wants to count words today.
For that reason, he asks the user to provide some.
> main = interact wordCount
> where wordCount input = show ( length input ) ++ "\n"
Tools that use comments for text:
Great for one-file examples with long text.
Disemphases code structure.
Good high-level documentation is not written code-first.
Why not attempt to solve to problem by starting with documentation and then referring to tested code?
Lets continue by defining a hello world application.
Talking to the machine about code is a hard problem.
Documentation is a very interesting problem from a hackers perspective. Let’s improve!
For most daily applications, the technological problems are solved, but badly documented. We have a learning problem at hand.
All pictures by @dariocravero and myself.
Slides with links at: http://skade.github.io/presentations/unicorns.html
Fork me on Github