That would be feasible up to an extent. Detecting there are two
describe "a" ... in different files is pretty easy, but when we get to more dynamic ones (
describe ("should " ++ description) ...), it gets a lot trickier. I think we’d also have to properly handle and detect nesting of describes to avoid false positives.
We at some point decided to enforce this by the tool itself because it was the only tool really able to tell whether there were duplicate titles. I proposed the same change to
elm-test (on the same day as for the other proposal, didn’t remember that!), and we since then have that feature in
elm-test. Sorry/not sorry for the pains that has caused people
Anyway, that is to say that
elm-review could help out a bit, but not perfectly. And I guess in this case it would only be useful for the migration, so the value is short-lived. Sorry for the maybe unneeded trip to memory/history lane
If that is the problem, I guess a nice solution would be for
elm-test-rs to list all the problems instead of reporting them one by one, as @neurodynamic suggested too. Also, using the watch mode should help the flow here.
Also, I think it would be very nice if both
rtfeldman/node-test-runner could agree on this behavior (one way or another), so that choosing one tool over the other is up to the user. I feel like they are so close to each other that it’d be a shame to differ on this tiny piece (but that could fail the tests when run when one tool and not the other).
I think the
elm-tooling CLI intends to support it when it gets released.