Proposal to Separate Immutable Tests in `high-scores`

Exercism
1

Hi everyone :wave:

While working on the high-scores exercise, I noticed that the last four test cases under the "Top 3 scores" section (starting here) serve a fundamentally different purpose.

These tests are marked with the scenarios: ["immutable"] field (used by test generators) and are designed to ensure that the original input array of scores is not mutated. Unlike the rest of the section, which focuses on the personalTopThree property, these:

  • Introduce entirely different properties (latestAfterTopThree, scoresAfterTopThree, etc.), which are more like combinations of existing properties than standalone ones.
  • Serve a distinct purpose: verifying immutability rather than sorting or ranking logic.
  • And notably, the last two tests don’t involve the personalTopThree property at all.

:bulb: Suggested Change

To improve clarity, I propose moving these four tests into their own section, perhaps titled "Immutable operations", to better reflect their purpose and avoid conflating them with the personalTopThree tests.

Would love to hear your thoughts before I open a PR!

2

On the one hand, more clarity is always better. On the other hand, students don’t see the problem spec data so adding a new section doesn’t actually change what students see … and would break any tracks that use a test generator for this exercise.

3

I wasn’t aware of that! :upside_down_face:

While working on adding the missing tests to the JavaScript track for this exercise (@Cool-Katt merged that PR), I noticed that it would make more sense to separate those last four tests into their own section. That observation is what led to this suggestion.

Of course, if the disadvantages outweigh the benefits, I’m totally open to rethinking the proposal!

4

I’m a tad confused. Doesn’t the scenarios: ["immutable"] field call out / group these test cases already in problem-specifications?

That would be the field that a test generator or maintainer would look at to omit these cases if they weren’t wanted on the track.

For reference, see the generated test file for this exercise in Python, which did decide to include them.

What would you want to happen differently with your proposal? What would the proposed change be intended to do? What would the test file look like?

1 Like
5

I agree that it doesn’t make much of a difference for tracks like Java and Python that don’t have nested tests (as you demonstrated in the generated test file). However, there are tracks like JavaScript and TypeScript where tests are nested. For example, take a look at the test file in the JavaScript track for this exercise. The tests appear under the Top 3 scores section, just as they are grouped in the problem-specifications repo.

That said, I believe these tests don’t technically belong in the Top 3 scores section, which is why I proposed moving them into a separate section altogether out of the Top 3 scores.

I understand that the scenario: ["immutable"] tag already “kind of” separates them, but that distinction isn’t reflected in the generated test files for tracks with nested test structures, and they still appear under the same grouped section.

I understand the confusion here. You mentioned:

That’s a fair assumption, but from what the documentation indicates, the primary purpose of the scenarios tag is to signal to the test generator that these tests should be treated as special cases, often to be skipped or handled differently, rather than to group them under a main section. So while it might appear that scenarios helps with grouping, it’s not actually meant to serve that role within the structure of problem-specifications.

As for what the test files would look like after this proposal, there is no one-size-fits-all answer. Tracks that support nested tests (like JS/TS) would likely see meaningful structural changes, whereas flat-test tracks (like Java/Python) might remain visually unchanged.

6

Does that make sense? I’m not very good at explaining things!