-
Notifications
You must be signed in to change notification settings - Fork 619
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
Comments
I have an implementation for this, but am waiting on 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). |
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. |
Especially while Deno is still new and it’s possible to get everyone to follow the convention. |
Yes, this will be cli only, at least initially. It will import from filenames that match |
I also agree that convention > configuration, so I'll support you in following the |
FYI I'm working on it |
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:I'm open to suggestions on how this would work, this was just my first thoughts on it.
The text was updated successfully, but these errors were encountered: