Support tests in subfolders

[Falco Nogatz]

I don't want to put all tests in one directory. Currently interpreted throws on subdirectories like source/sub/example.yaml and expected/sub/example.json. Is there a way to run the tests for the files in all subfolders as well?

Error message:

/[...]/node_modules/interpreted/interpreted.js:97
      if (err) throw err;
                     ^
Error: EISDIR, read

[Andreas Madsen]

Not currently, but I will take a pull request.

[Falco Nogatz]

Actually it's really hard to contribute. I don't really understand your way to use tap. Why do you spawn child processes in the /test/runner.js script while tap could handle all files in the /test subfolder natively? It's not even possible to simply copy the /test/all-good/ directory, add a

test('all good copy', runTest('all-good-copy'));

to your runner.js without getting an error. tap's native way to implement tests is much more nice and predictable.

[Andreas Madsen]

Sorry for not getting back to you earlier.

The reason why I use a spawn is because I want the actual tap stdout output, if ran the subtests in the runner.js process, it wouldn't really tell me anything. e.q imagine that interpreted always passed its tests as true, now all the runner.js would be pass as true, but in fact the module is very broken. By using the tap output and match it against a static file, this false positive can be prevented.

I do agree that the tests are very ugly, but the sad truth is that in order to get pretty tests you would need interpreted to match a test directory against a file. Which as discussed before would lead to false positive.

As for the error you are getting, I believe you just need to add a all-good-copy.txt file in the fixture directory, the pro tip here is to change the readFile to a writeFile with actual as an expected parameter run the tests and change it back again (remember to run git status to make sure it didn't change any of the order tests).

Because the interpreted test runner it self is an example of where you wouldn't want the directories to recursively walked, I would like you make the feature an option, but you may default it to true as I think your use case is the normal use case.