anchor.diff:      GeneratorTask.new(:generate, HtmlGenerator) do |task|
         task.output_dir = 'test/examples/shiny'
         task.templates_path = 'data/templates'
  +      #
  +      # add extra input examples (optional)
  +      task.examples_path.unshift 'test/examples/asciidoc'
       end
     end
   end
  
positive.code: 
  ----
  
  === Custom
  
  You can extend DocTest to support any textual format you want. All what you need is to implement
  a custom suite parser (extend link:{src-base}/base_suite_parser.rb[BaseSuiteParser]), a test class
  (extend link:{src-base}/base_test.rb[BaseTest]) and optionally a generator (extend
  link:{src-base}/base_generator.rb[BaseGenerator]).
  
  
  == Generate examples
  
  Writing examples of an expected output for all the reference
  input examples from scratch is quite a chore. Therefore DocTest provides a
  generator, so when you have at least partially working Asciidoctor _backend_
  (converter or set of templates), you can pass the input examples through it and
  generate your output examples. Then you should verify them and modify if
  needed.
  
  Assume that you have defined the generator Rake task named `:generator` (see
  <<setup-doctest>>).
  
  Now you can generate output examples from all the reference examples (with
  `.adoc` extension) found on the `examples_path` that doesn’t already exist
  (i.e. it doesn’t rewrite existing):
  
  [source, sh]
  bundle exec rake generate
  
negative.code: task :default => :test
  ----
  
  
  == Run tests
  
  Assume that you have defined the test Rake task named `:test` (see above).
  Then you can simply run:
  
  [source, sh]
  bundle exec rake test
  
  
  == Examples
  
  Test _example_ is just a document fragment — in AsciiDoc syntax (a reference input) or the backend’s target syntax (an expected output) — that should ideally cover one use case from the perspective of the generated output (i.e. code branch in converter or template).
  Examples are grouped in so called _example suites_; each focusing on one block or inline element — more precisely Asciidoctor’s AST node (paragraph, table, anchor, footnote…).
  
  Examples suite is stored in a textual file named by the AST node (e.g. block_table, inline_anchor…, see the list below) with an extension according to its syntax (e.g. `block_table.adoc`, `block_table.html`) — similarly as Asciidoctor templates.
  Individual examples in the suite are separated by a special header with the name of the example, an optional description and options.
  This header should enclosed as a comment (so you can render the examples suite as a valid AsciiDoc/HTML/TeX/… document).
  
  Each example is uniquely identified with its name and the suite name like this: `{suite_name}:{example_name}` (e.g. `block_table:with_title`).
  Input and output examples are paired — for every input example there should be an output example with the same identifier.
  When you run test, the input example is converted using the tested backend (or templates) and its actual output is compared with the (expected) output example.
  
  [horizontal]
  .List of Asciidoctor’s AST nodes
  document:: TODO
  embedded:: TODO
  section:: {doctor-man-uri}/#sections[document sections], i.e. headings
  