testdouble / docunit Goto Github PK

like any test tool, a lot of configuration will be necessary to be usable. my idea here is to have a global config passed to docunit(globs, [config]) with some properties like:

• before(cb) and after(cb) - invokes cb with ('example|file|all', text|path|??), respectively, each invoked outside the vm/context the tests are run
• setup/teardown(cb) - invokes cb for each file|example|all invoked inside the vm/context the tests are run
• freshVmPer: example|file|all - start a fresh VM for each example, file, or all
• language - JS|Coffee|Babel|Ruby, etc, which will require a registered plugin from docunit to be able to compile

If any config options are static and differ between files, some CSON front matter could be used on a file-by-file basis, a la:

language: 'ruby'

it's too hard to tell if your file just got missed.

for people who want to include this in their test reports

Read in a single markdown file, find the code example, run it:

• test for a passing code example
• test for a failing code example

a CLI command called docunit that takes as arguments paths/globs

right now any code blocks docunit executes will see their require() calls (if they have any) executed from the docunit run-in-.....js file. should be relative to wherever the markdown file lives.

an adapter API to register (on a per-process basis, via docunit.register()) adapter functions for things like coffee-script & babel to be able to run those languages.

The config for which lang we're looking at will be with three levels of locality:

• global config, whatever is passed to docunit('paths', config) as language
• file config, whatever's in the CSON frontmatter of the markdown file language key
• example block, whatever name follows the "", like " coffee", allowing users to mix and match within a file

register should receive an object with properties:

• assertionFor -- function passed a string line, the provided function should split on any inline comments found and return falsey (no assertion needed) or an object containing expected and actual strings. docunit will replace the line with lines to save off the values and include an asserty
• compile - function to compile any given block of code, probably just delegating to coffee/babel, etc; the compiled output needs to preserve code comments, which means CoffeeScript is out, but babel has an option

right now throwing an error in a code block will break the test as well

throw new Error("LOL")

A config option should probably be available to squash these as some docs obviously want to throw errors