Feature request: test selection
- Dominant language
- Gleam
- Stars
- 49
- Forks
- 38
- PR merge metrics
- No merged PRs in 30d
Description
Test frameworks for other languages often have a way to filter which test are run, which is useful for iterating on a single test without having to run every test. Examples are [cargo test](https://doc.rust-lang.org/cargo/commands/cargo-test.html), [python's unittest](https://docs.python.org/3/library/unittest.html#command-line-interface), [mix test](https://mix.hexdocs.pm/1.20.2/Mix.Tasks.Test.html), and [unitest](https://unitest.hexdocs.pm/). While gleeunit intends to be a simple test runner, and in the past you've expressed a lack of interest in new features, I think a way to filter based on filename or test name is simple enough and extremely useful for iterating on core packages that it would be a good fit for gleeunit.
My proposal is to add two new command line switches, `--include` and `--exclude` that each take a list of function names to include or exclude. To keep things simple, each switch can only be used once, and specifying a test in both include and exclude will cause an error:
Example usage:
```sh
gleam test # run all tests
gleam test --include foo_test # only run foo_test
gleam test --include foo_test bar_test # only run foo_test and bar_test
gleam test --exclude baz_test # run all tests except baz_test
gleam test --include foo_test bar_test --exclude bar_test # error! bar_test included and excluded
```
This should be simple to implement without adding any complexity to the existing code, and can be done without any dependencies outside of gleam_stdlib. If you're interested in this feature I'd be happy to work on it!
Contributor guide
No contributing guide indexed for this repository
Research direction
Start at the `gleam test` command and trace how test names are discovered and selected by gleeunit. Implement the single-use `--include` and `--exclude` switches, reject tests named in both lists, and verify that the examples run the expected subset.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- erlang
- Domain
- cli, testing
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100