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

non-exhaustive tests #81

Open
10 of 11 tasks
Average-user opened this issue Mar 7, 2019 · 6 comments
Open
10 of 11 tasks

non-exhaustive tests #81

Average-user opened this issue Mar 7, 2019 · 6 comments

Comments

@Average-user
Copy link
Member

Average-user commented Mar 7, 2019

As explained here #80 there is a way to write tests that is not exhaustive enough. As an example, if we have a simple program like:

add(X,Y,Z) :-
 Z >= X+Y.

A test like:

?- add(1,2,3).
true.

succeeds. When is obviously not correct. nevertheless if we do this:


?- add(1,2,X).
ERROR: Arguments are not sufficiently instantiated
ERROR: In:
ERROR:    [9] _2658>=1+2
ERROR:    [7] <user>
ERROR: 
ERROR: Note: some frames are missing due to last-call optimization.
ERROR: Re-run your program in debug mode (:- debug.) to get more detail.

throws an error. In this case, this predicate should be tested like so add(1,2,X), x =:= 3.

This is a particular characteristic of Prolog, and that is why is particularly confusing.

This are all tests that have this flaw:

  • anagram
  • binary
  • complex-numbers
  • grains
  • hamming
  • nucleotide-count
  • pascals-triangle
  • rna-transcription
  • spiral-matrix
  • sum-of-multiples
  • triangle

If you submit a PR to fix one of them, please refer to this issue. And if you find another exercise with this problem add a comment here.

@neenjaw
Copy link
Collaborator

neenjaw commented Oct 10, 2019

I am working on the triangle problem's tests, and at the same time referencing https://github.com/exercism/problem-specifications/blob/master/exercises/triangle/canonical-data.json to make the tests congruent to the canonical tests. In this test I am concern about how the example implementation limits itself to a single answer because the test days proposes the following test case:

        {
          "description": "equilateral triangles are also isosceles",
          "property": "isosceles",
          "input": {
            "sides": [4, 4, 4]
          },
          "expected": true
        },

which if we test for explicitly triangle(4,4,4, "isosceles") returns true, but under this proposed change with the example solution triangle(4, 4, 4, Result), Result == "isosceles" returns false. If I just remove the ! from the equilateral predicate, then it will succeed with a choicepoint.

Is there a way to accept the test with a choicepoint without raising a warning? Or should the test be changed to findall(R, triangle(4,4,4, R), Rs), member("isosceles", Rs).

I think we should aim to be conformant to the canonical tests, so this requires an interface change somewhere. Thoughts?

@Average-user
Copy link
Member Author

Maybe triangle does not need to be fixed.

@neenjaw
Copy link
Collaborator

neenjaw commented Oct 10, 2019

I think it all depends on how we want to view the query. triangle(+SideA, +SideB, +SideC, +Type) or triangle(+SideA, +SideB, +SideC, -Type) or triangle(+SideA, +SideB, +SideC, ?Type). If we want a deterministic answer (which may be the purest prolog solution), then maybe we shouldn't fix it.

(edit) Had more time to think/read. Changed my mind.

ErikSchierboom added a commit that referenced this issue Mar 31, 2023
Co-authored-by: Erik Schierboom <erik_schierboom@hotmail.com>
ErikSchierboom added a commit that referenced this issue Mar 31, 2023
Co-authored-by: Erik Schierboom <erik_schierboom@hotmail.com>
ErikSchierboom added a commit that referenced this issue Mar 31, 2023
ErikSchierboom added a commit that referenced this issue Mar 31, 2023
ErikSchierboom added a commit that referenced this issue Mar 31, 2023
ErikSchierboom added a commit that referenced this issue Mar 31, 2023
ErikSchierboom added a commit that referenced this issue Mar 31, 2023
ErikSchierboom added a commit that referenced this issue Mar 31, 2023
@ErikSchierboom
Copy link
Member

I think it all depends on how we want to view the query. triangle(+SideA, +SideB, +SideC, +Type) or triangle(+SideA, +SideB, +SideC, -Type) or triangle(+SideA, +SideB, +SideC, ?Type). If we want a deterministic answer (which may be the purest prolog solution), then maybe we shouldn't fix it.

(edit) Had more time to think/read. Changed my mind.

@neenjaw What do you suggest we do with triangle?

ErikSchierboom added a commit that referenced this issue Mar 31, 2023
ErikSchierboom added a commit that referenced this issue Mar 31, 2023
ErikSchierboom added a commit that referenced this issue Mar 31, 2023
ErikSchierboom added a commit that referenced this issue Mar 31, 2023
ErikSchierboom added a commit that referenced this issue Mar 31, 2023
ErikSchierboom added a commit that referenced this issue Mar 31, 2023
@neenjaw
Copy link
Collaborator

neenjaw commented Apr 3, 2023

I haven't really thought about this issue for a long time, but I lean towards the problem set being written in such a way to promote deterministic solutions. I think those are better supported from the unit test library (if I recall correctly).

@cpmachado
Copy link
Contributor

#289
Just linking this here for triangle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants