Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sync: tests.toml should contain upper level descriptions of nested tests #202

Closed
SaschaMann opened this issue Feb 26, 2021 · 1 comment · Fixed by #301
Closed

sync: tests.toml should contain upper level descriptions of nested tests #202

SaschaMann opened this issue Feb 26, 2021 · 1 comment · Fixed by #301
Labels
cmd: sync kind: feature User-facing enhancement

Comments

@SaschaMann
Copy link
Contributor

Canonical data may contain nested tests, e.g.

{
      "description": "isosceles triangle",
      "cases": [
        ...
        {
          "uuid": "840ed5f8-366f-43c5-ac69-8f05e6f10bbb",
          "description": "no sides are equal",
          "property": "isosceles",
          "input": {
            "sides": [2, 3, 4]
          },
          "expected": false
        },
        ...
}

In tests.toml, only the inner-most description is currently added to the description key. For some exercises, like triangle, this leads to several cases having identical descriptions, which makes tests.toml harder to read as a maintainer.

Merging the descriptions of all nesting levels may clear things up. The example above could be translated to

description = "isosceles triangle → no sides are equal"

Note that there may be more than two levels that need to be merged, since nesting is not limited by the canonical-data spec.

Alternatively, there could be a new key super = "isosceles triangle" though it's not clear how this would work for tests with more than one nesting level.

@SaschaMann SaschaMann changed the title tests.toml should merge descriptions of nested tests tests.toml should contain upper level descriptions of nested tests Feb 26, 2021
@ErikSchierboom
Copy link
Member

Merging the descriptions of all nesting levels may clear things up. The example above could be translated to

description = "isosceles triangle → no sides are equal"

I really like this suggestion!

ErikSchierboom added a commit that referenced this issue May 2, 2021
Some problems defined in the problem-specifications repo are defined using nesting. configlet handles these nicely, but the description of the `tests.toml` files only contains the description of the test case itself, which can be confusing if test cases in different nested objects have the same description.

This commit writes the full description to the `tests.toml` file. For example, `Test group description → Test case description` for a singly-nested test case.

See #202
ee7 pushed a commit that referenced this issue May 5, 2021
Some problems defined in the problem-specifications repo are defined
using nesting. configlet handles these nicely, but the description of
the `tests.toml` files only contains the description of the test case
itself, which can be confusing if test cases in different nested objects
have the same description.

This commit writes the full description to the `tests.toml` file. For
example,
`Test group description → Test case description`
for a singly-nested test case.

See #202
@ee7 ee7 changed the title tests.toml should contain upper level descriptions of nested tests sync: tests.toml should contain upper level descriptions of nested tests May 9, 2021
@ee7 ee7 added cmd: sync kind: feature User-facing enhancement labels May 10, 2021
ErikSchierboom added a commit that referenced this issue May 22, 2021
Some problems defined in the problem-specifications repo are defined
using nesting. configlet handles these nicely, but the description of
the `tests.toml` files only contains the description of the test case
itself, which can be confusing if test cases in different nested objects
have the same description.

This commit writes the full description to the `tests.toml` file. For
example,
`Test group description → Test case description`
for a singly-nested test case.

See #202
ErikSchierboom added a commit that referenced this issue May 22, 2021
Some problems defined in the problem-specifications repo are defined
using nesting. configlet handles these nicely, but the description of
the `tests.toml` files only contains the description of the test case
itself, which can be confusing if test cases in different nested objects
have the same description.

This commit writes the full description to the `tests.toml` file. For
example,
`Test group description → Test case description`
for a singly-nested test case.

See #202
@ee7 ee7 closed this as completed in #301 Jun 2, 2021
ee7 added a commit that referenced this issue Jun 2, 2021
Some exercises in the `problem-specifications` repo have a
`canonical-data.json` file that uses nesting, meaning that there is more
than one `cases` property.

`configlet` handled these nicely, but each `description` in each
`tests.toml` file contained only the description of the test case
itself. This could be unclear, and was especially confusing when test
cases in different nested objects had the same description. Each
`description` is purely for humans to read - it isn't used otherwise.

With this commit, `configlet sync` writes the "full description" to the
`tests.toml` file. For example, a `tests.toml` for the `triangle` 
exercise might previously contain (omitting other test cases for
clarity):

```toml
[3022f537-b8e5-4cc1-8f12-fd775827a00c]
description = "sides may be floats"

[adb4ee20-532f-43dc-8d31-e9271b7ef2bc]
description = "sides may be floats"

[26d9d59d-f8f1-40d3-ad58-ae4d54123d7d]
description = "sides may be floats"
```

But with this commit:

```toml
[3022f537-b8e5-4cc1-8f12-fd775827a00c]
description = "equilateral triangle → sides may be floats"

[adb4ee20-532f-43dc-8d31-e9271b7ef2bc]
description = "isosceles triangle → sides may be floats"

[26d9d59d-f8f1-40d3-ad58-ae4d54123d7d]
description = "scalene triangle → sides may be floats"
```

For the canonical data for this exercise, see:
https://github.com/exercism/problem-specifications/blob/f17f457fdc06/exercises/triangle/canonical-data.json

We decided that putting everything in `description` is better than:
- adding extra key/value pair(s) named e.g. `category` or `super`
- adding TOML comments
- using sub-tables

While working on this PR, we noticed that 18 exercises in
`problem-specifications` had unnecessary nesting. We simplified them in
exercism/problem-specifications#1798

Closes: #202

Co-authored-by: ee7 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cmd: sync kind: feature User-facing enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants