Testing

All extension test were changed to use a modified spec.txt format which combines documentation, markdown source and expected HTML result.

The format was modified to add AST output to allow testing of the generated AST which is crucial for using this parser for syntax highlighting.

The markdown headers in the spec are used to mark sections. Each test case has the following format:

```````````````````````````````` example
 - foo
   - bar
→ - baz
.
<ul>
<li>foo
<ul>
<li>bar
<ul>
<li>baz</li>
</ul>
</li>
</ul>
</li>
</ul>
.
Document[0, 24]
  BulletList[1, 24]
    ListItem[1, 24] open:[1, 2]
      Paragraph[3, 7]
        Text[3, 6]
      BulletList[10, 24]
        ListItem[10, 24] open:[10, 11]
          Paragraph[12, 16]
            Text[12, 15]
          BulletList[18, 24]
            ListItem[18, 24] open:[18, 19]
              Paragraph[20, 24]
                Text[20, 23]
````````````````````````````````

The first part is the markdown source, the expected HTML is separated by single . on the line. Expected AST is added as a third part to the original spec.txt.

I find this format to be an excellent way of generating tests. To make creation of expectations easier I added a FullSpecTestCase class to be inherited by extension tests. This test replaces the expected HTML and AST with the result from parsing the source. Then the full text is compared to the original file. The purpose of this is to use the difference of this test to update the test file, preferably with a diff/merge tool to ensure that no inadvertent changes are made.

The best way to create an extension is to start with a copy of an existing one and modify the source and tests to suit the new extension.