Test suite about archieml-js

[gka]

Example: https://github.com/newsdev/archieml-js/blob/inline-comments/test/parse-documents-test.js

This vows test checks for *.aml files in /test/test-documents/, parses them and compares the output to the corresponding json file.

https://github.com/newsdev/archieml-js/tree/inline-comments/test/test-documents

[gka]

sorry for mixing this into the inline-comments branch, btw

[abstrctn]

Hi @gka - I'm realizing now that the README was missing a step for the existing test suite: there are a series of shared tests available to all parsers in the newsdev/archieml.org repository, but since they're included as a submodule, you have to run git submodule update --init in order to download them, and then nodeunit to run them:

$ git submodule update --init
Submodule 'test/archieml.org' (https://github.com/newsdev/archieml.org) registered for path 'test/archieml.org'
Cloning into 'test/archieml.org'...
remote: Counting objects: 480, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 480 (delta 0), reused 0 (delta 0), pack-reused 477
Receiving objects: 100% (480/480), 331.45 KiB | 0 bytes/s, done.
Resolving deltas: 100% (171/171), done.
Checking connectivity... done.
Submodule path 'test/archieml.org': checked out 'b2e516d590097f18c693d775edcbc1ebbef6111b'

$ nodeunit

loader
✔ loaderTests

shared
✔ sharedTests

OK: 170 assertions (95ms)

That shared test model obviously has some disadvantages though, since it requires A) git submodules, and B) the way that the source AML and expected JSON output are included in the same file is unfamiliar to everyone but me at 2 a.m.:

Example test

test: [array] creates an empty array at array
result: {"array": []}

[array]

The shared.js test runner strips out the first two lines, then checks that the rest of the document gets parsed as {"array": []}: https://github.com/newsdev/archieml-js/blob/inline-comments/test/shared.js#L49-L56

---

I kind of liked how that kept the source and expected output within the same file (just for ease of editing), but maybe it's worth splitting them into separate files like you had if that's a more familiar pattern to others?

We can also get rid of the submodule and check the tests directly into the app so it's more straightforward to run + edit, but if so we should find another way to keep the tests in sync?