Tests improvement for Triangle exercise


I recently solved Triangle exercise and noticed that “For a shape to be a triangle at all, all sides have to be of length > 0” rule is not fully checked in tests.
we have only test where all 3 sides are 0, but not when only A is 0.

Should be easy change.

I feel like this doesn’t really need to be added.
The logic of all sides have to be of length > 0 can be inverted to be if ANY side is <= 0, which the [0, 0, 0] test already check for.

Not always. E.g. in this solution on Erlag:



% all 0 length is not a triangle
kind(0, 0, 0) ->
  {error, "all side lengths must be positive"};
%% first check that is it a valid triangle
kind(A, B, C) ->
  [Min, Med, Max] = lists:sort([A,B,C]),
  case {Max, Med + Min} of
    {Max, Sum} when Sum < Max ->
      {error, "side lengths violate triangle inequality"};
    _ ->
      identify(A, B, C)

identify(A, A, A) ->
identify(A, A, _) ->
identify(_, A, A) ->
identify(A, _, A) ->
identify(_, _, _) ->

test with [0,0,0] will pass (invalid triangle), but [0,0,1] will be considered valid ‘isosceles’ triangle.

Let a, b, and c be sides of the triangle. Then all three of the following expressions must be true:

a + b ≥ c
b + c ≥ a
a + c ≥ b

The [0,0,1] would fail inequality test, not considered valid isosceles triangle.

Completely agree with you. That was my original proposal - add more tests.
[0,0,1], [0,1,0],[1,0,0],[0,1,1],[1,0,1],[1,1,0]

I think I see where is the problem now.

First thing first, I was wrong in my earlier post.
[0, 0, 1] should fail the all side lengths must be positive test first. Not the inequality test.

This issue seem to stem from the pattern matching ability of some languages and the way the test suited being constructed.

In python and C# for exmaple, the test suite give you a bunch of functions to test for true or false like IsScalene, IsIsosceles, etc. So it shouldn’t matter much which test the triangle fail, it only want a boolean value return.

In PowerShell I made it so it asked for an Enum value (SCALENE) and specific error message, somewhat similar to the one in Erlang. And I think we are the ones that veer away from the problem-specifications a bit.

That is to say asking for 6 additional test cases to add into the specs is quite unreasonable for other maintainers. Your best bet in this case is to ask the Erlang maintainer to consider to add the [0,0,1] test for the exercise for the track.

If the tests add clear value across languages, I think it’s quite reasonable. Note, I haven’t been paying close enough attention here to have an opinion of the value this would add across tracks.