Triangle canonical data: add scenario for triangle inequality violation

Exercism Building Exercism
, ,
1

The comments of the canonical data include this:

How you handle invalid triangles is up to you. These tests suggest a
triangle is returned, but all of its properties are false. But you
could also have the creation of an invalid triangle return an error
or exception. Choose what is idiomatic for your language.

For example:

        {
          "uuid": "90efb0c7-72bb-4514-b320-3a3892e278ff",
          "description": "third triangle inequality violation",
          "property": "isosceles",
          "input": {
            "sides": [3, 1, 1]
          },
          "expected": false
        }

It would make it easier for tracks with generators if there was a scenario there. Then the generator could more easily decide when to throw an error, versus simply test for “not isosceles”.

Perhaps:

        {
          "uuid": "90efb0c7-72bb-4514-b320-3a3892e278ff",
          "description": "third triangle inequality violation",
      =>  "scenarios": ["input-validation"],
          "property": "isosceles",
          "input": {
            "sides": [3, 1, 1]
          },
          "expected": false
        }

This would not be a major change as the Readme says:

The scenarios field can be mutated additively, by adding new scenarios. Existing scenarios must not be changed or removed. Adding new scenarios does therefore does not mean adding a new test case.

2 Likes
2

How would that differentiate between a valid non-isosceles triangle and an invalid isosceles-looking triangle? The expected: false on both scenarios seems to suggest there is a specific expected behavior for invalid triangles.

3

Assuming I understand the suggestion correctly:

Within the new scenario, a generator could expect an “invalid triangle” exception to be thrown. Outside the new scenario, a generator could expected isosceles? to return true/false according to expected. So the generator would no longer need to contain its own triangle-validation logic.

4

What is an “invalid isosceles-looking triangle”?

The test generator can look for the scenario and decide:

  • “input-validation” is the scenario: I’m going to expect the user to throw an error when I give them [3, 1, 1]
  • there are no scenarios for some other test case: I’m going to expect the user to return false when I ask if [3, 3, 1] is scalene.
5

3,1,1

Got it. I think. If I understand correctly, “input-validation” implies “invalid input”. I would suggest being explicit. With a more explicit name, this sounds good to me.

6

The scenario names are constrained by the json schema, I was picking an existing one.

“input-validation” implies “invalid input”

Yes exactly: [3, 1, 1] is an invalid triangle, so it is invalid input.

7

Of course I do have a self-serving reason for bringing this up. I’ve been poking away at creating a MoonScript track. (MoonScript is like CoffeeScript for Lua)

A test generator function might look like

  generate_test: (case, level) ->
    if type(case.expected) == 'number'
      indent "assert.are.equal #{case.expected}, prime #{case.input.number}", level
    else
      indent "assert.has.errors (-> prime #{case.input.number}), #{quote case.expected.error}", level

In this case I’m branching between a “normal” test and an “error” test based on the type of the expected property of a test case in the canonical data: “expected” is a number or it’s an object with an “error” property. But for the triangle exercise, there’s nothing to branch on.

8

I wouldn’t want to require the test maintainer to analyze the data to determine if it is or isn’t valid. The data itself ought to clearly indicate that it is invalid.

9

Maintainers already have to do that for this exercise. Reread the comments at the top of the canonical data.

What I hear that you’re saying: if maintainers want to write a test generator and also choose to throw errors for this case, then they have to implement the program logic in the test generator as well as the example solution.

I will also point out that adding a scenario to these test cases is simply the addition of a piece of data that is used to clearly indicate …