frondeus / frondeus/test-case

Bad custom test names should not fail silently

Open
#72 4 comments 0 reactions 0 assignees View on GitHub
enhancement spike
Dominant language
Rust
Stars
633
Forks
42
PR merge metrics
No merged PRs in 30d

Description

I will be borrowing the example from #19, since it has some relation to how I found this error on my own code.

So, we know from that issue that the minus will be abstracted from the automatic name creation process, BUT, we have a mechanism for custom names, and that could help the developer to understand that the problem with his code is that he is lacking a valid test name:

```
#[test_case(15, 15; "Abs_15_15")]
#[test_case(-15, 15; "Abs_-15_-15")]
fn test_crazy_stuff(value: i32, expected: i32) {
assert_eq!(value.abs(), expected)
}
```

And this will raise a familiar error, but the interesting part is that it tried to use my custom name, since it begins with `abs`, and not `test_crazy_stuff`:

```
error[E0428]: the name `abs_15_15` is defined multiple times
--> src/lib.rs:162:5
|
162 | #[test_case(15, 15; "Abs_15_15")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| `abs_15_15` redefined here
| previous definition of the value `abs_15_15` here
```

This leads me to believe that we have a process that tries to make the name valid, since it erased the hyphen from my custom test, applied, and then we had a name collision.

I haven't tried to analyze the code to understand how the hyphen is erased in both cases, but, i believe that if a developer instantiates a custom name, it shouldn't be safeguarded, if the name is invalid it should break catastrophically warning the developer of what the problem is.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.