Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a test runner #193

Closed
luvies opened this issue Feb 15, 2019 · 6 comments · Fixed by #516
Closed

Provide a test runner #193

luvies opened this issue Feb 15, 2019 · 6 comments · Fixed by #516

Comments

@luvies
Copy link

luvies commented Feb 15, 2019

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
Copy link
Contributor

hayd commented Feb 16, 2019

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
Copy link

jbreckmckye commented Feb 17, 2019

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
Copy link

j-f1 commented Feb 18, 2019

Besides, convention > configuration.

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

@hayd
Copy link
Contributor

hayd commented Feb 18, 2019

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
Copy link
Contributor

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

@ry ry mentioned this issue Jun 7, 2019
43 tasks
@bartlomieju
Copy link
Member

FYI I'm working on it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants