Provide a test runner

[luvies]

I was wondering if it would be reasonable to provide a test runner that (with some config) searched for, loaded, and ran all tests of a project? I'm personally not quite a fan of having to import all the tests manually and run them like that, and I feel like it could potentially be a little limiting. Plus, having a test runner that searches and executes tests would allow us to spin up sub-processes to handle executing a large number of test suites in parallel, and handle the output properly. It would also allow us to provide a nice interface as well, and support doing things like watching for changes on disk and re-running the tests.

I'd be quite happy with writing this runner, but I'd prefer to make sure that this would be reasonable to do first, and if so, know what it should look like before implementing anything. My first thought is to make the runner read a configuration file (e.g. test.config.ts, this would also be a command line argument to support a custom config file), and in that you give the regex/glob matcher that is used when walking the directories in search of tests. Something like:

export default {
  include: /.*\.test\.ts^/,
  exclude: /scripts/
}

I'm open to suggestions on how this would work, this was just my first thoughts on it.

[hayd]

I have an implementation for this, but am waiting on import() to be supported in deno.
(It was in ~0.2.8 and the test runner was working.)

Note: After #192 walking is easy, and if we wanted to support glob as a cli we could move https://github.com/hayd/deno-globrex over to std (or port something else).

[jbreckmckye]

An inbuilt test runner is not a bad idea. But at this stage I probably wouldn't write / consume any config files. That seems a second-order priority to getting parallelisation and file watching going. Besides, convention > configuration.

[j-f1]

Besides, convention > configuration.

Especially while Deno is still new and it’s possible to get everyone to follow the convention.

[hayd]

Yes, this will be cli only, at least initially. It will import from filenames that match /(.+_)?test\.ts$/ but could later take a glob as an arg. It also will --grep on test name if passed (only run matching tests). More features could be added in the future...

[jamesseanwright]

I also agree that convention > configuration, so I'll support you in following the _test suffix.

[bartlomieju]

FYI I'm working on it