lpil / lpil/gleeunit

Feature request: test selection

Open
#73 0 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.