Stream: ideas

Topic: Ignoring tests

Luke Boswell (Jul 18 2024 at 22:28):

Just thought I'd mention this while I'm thinking of it.

But I'd love a way to #[ignore] a roc expect test. I currently go through and comment/uncomment code and it's less than idea.

Richard Feldman (Jul 18 2024 at 22:58):

I'm kinda curious what people think about this topic

Isaac Van Doren (Jul 18 2024 at 23:15):

I think in the context of a single code change where you just need to temporarily disable a test, commenting it out is comparable to having a dedicated way to ignore. Doing cmd+/ is very easy.

The main benefit I see for ignoring tests is when something can’t be fixed for an extended period and you want the tooling to remind you that it needs to be fixed. That doesn’t seem like a very common case though. In practice you’d probably have a bug ticket/issue tracking the problem, so deleting the tests and restoring from version control would be sufficient.

Brendan Hansknecht (Jul 19 2024 at 00:09):

I think #[ignore] is much better:

1. the tooling tells you how many tests are ignored
2. once we have effectful tests, we may want to ignore tests in specific configs anyway
3. the cli can have a config to run ignored tests anyway so you can see which are passing.
4. the compiler can ensure that ignored tests still roc check and don't just bitrot away as apis change

Richard Feldman (Jul 19 2024 at 00:14):

Brendan Hansknecht said:

2. once we have effectful tests, we may want to ignore tests in specific configs anyway

hm, what kind of configs? :thinking:

Brendan Hansknecht (Jul 19 2024 at 00:15):

Configs that don't want to hit a server? Or if you have effects that act different based on architecture

Brendan Hansknecht (Jul 19 2024 at 00:16):

but maybe I am thinking too low level with that comment

Richard Feldman (Jul 19 2024 at 00:20):

sorry, I think I'm misunderstanding what a config means here :big_smile:

Richard Feldman (Jul 19 2024 at 00:20):

like a Roc version of Rust's cfg or something?

Brendan Hansknecht (Jul 19 2024 at 00:30):

like a Roc version of Rust's cfg or something?

yeah

Richard Feldman (Jul 19 2024 at 00:54):

so like for different build targets?

Brendan Hansknecht (Jul 19 2024 at 01:05):

yeah. Different build target leads to different effect results.

Richard Feldman (Jul 19 2024 at 01:23):

I'd really like to avoid ever doing something like that if at all possible :sweat_smile:

Richard Feldman (Jul 19 2024 at 01:26):

I'd like an application author's mental model to be "I have one code base, and all of it always gets built all the time; if it build successfully on one target, it builds successfully on all the targets"

Richard Feldman (Jul 19 2024 at 01:28):

like I don't want to have to do the equivalent of cargo check with --target for all N targets I support to see if there are any type mismatches on any of my application's targets

Richard Feldman (Jul 19 2024 at 01:28):

rather, I want platform authors to design their APIs in such a way that target-specific differences are handled using ordinary conditionals (which might get optimized away depending on target)

Jasper Woudenberg (Jul 19 2024 at 06:23):

I always appreciate ignore test functionality as a short-term convience for myself, but dislike it in larger codebases collaborated on with a larger team :sweat_smile: . Because I think once a test is ignored for a while, it gets increasingly hard to move away from that state.

• Hard to delete the test, because it'd go against the judgement of whoever thought it was important to keep when they ignored it.
• Hard to make time for a fix, because the test has been ignored for a while so it's clearly not urgent. Plus the effort to fix it has probably gone up since we first ignored the test, given the test hasn't been ran for a while.

Last updated: Jun 17 2026 at 14:56 UTC