Property-based-tests Diamond.

[Average-user]

Here https://github.com/exercism/problem-specifications/blob/master/exercises/diamond/canonical-data.json you can see that in the diamond exercise, a property-based-test is possible. So, would be great if someone can implement a property-based-test in: https://github.com/exercism/haskell/tree/master/exercises/diamond. Meanwhile the value-based-test can do the work.

According to exercism/problem-specifications#191 (comment) it's not only possible to implement property-based-tests, it's preferred.

[rbasso]

I think it would be great to use QuickCheck in this exercise!

Have you identified all the properties to be tested, @Average-user?

With that, it would be easy to change the test suite using trinary, octal or simple-linked-list as inspiration.

[Average-user]

@rbasso If I had to do this, I will probably make my own property tests, but thats usually not welcome.

[rbasso]

If I had to do this, I will probably make my own property tests, but thats usually not welcome.

Why?

Usually the properties capture the essence of the solution, so I think people tend to find the same, "fundamental" ones, after pondering for a while.

That said, I'm still trying to find the minimal set of properties that define a diamond, so take everything that I just said with a grain of salt. 😄

[Average-user]

Usually the properties capture the essence of the solution

Yeah, I understand that, it is probably because of that, that I would try to make my own tests, and not use QuickCheck. But I don't know if I want to :\

[rbasso]

Usually the properties capture the essence of the solution

Yeah, I understand that, it is probably because of that, that I would try to make my own tests, and not use QuickCheck. But I don't know if I want to :\

To use QuickCheck, you would need to define the properties anyway, so I guess I'm probably not understanding what you mean by "create my own property tests" and "to make my own tests" that could be different from writing properties to be tested by QuickCheck, as we did in octal, trinary and simple-linked-list.

[Average-user]

To use QuickCheck, you would need to define the properties anyway, so I guess I'm probably not understanding what you mean by "create my own property tests" and "to make my own tests" that could be different from writing properties to be tested by QuickCheck, as we did in octal, trinary and simple-linked-list.

Mhh. My bad, I misunderstood what you said before.

But for example, instead of properties, you could use the same function that we are discussing on the other issue, and test all possible input-output relations, since they are finite (or just use a list with the explicit in-outs, that I would generate with the function anyway). This is kind of "cheating" maybe, or less general, but when testing all possibilities, you are completely sure that the program does what it should.

Of course you can't do this with every function, in fact you probably can't with most of them, and this is why I think you could even call this a "property".

[rbasso]

But for example, instead of properties, you could use the same function that we are discussing on the other issue, and test all possible input-output relations, since they are finite (or just use a list with the explicit in-outs, that I would generate with the function anyway). This is kind of "cheating" maybe, or less general, but when testing all possibilities, you are completely sure that the program does what it should.

I usually try to keep in mind some guidelines when trying to write tests:

• Tests should be progressive when possible, checking first things that are easier to get right.
• Things that are not a fundamental part of solving the problem shouldn't be tested.
• Test should cover at least the common implementation errors.
• The test suite should not reveal a solution to the problem.
• The test suite should be as idiomatic as possible.
• The test suite should be kept as simple as possible, easing maintenance.

Using an existing solution to check the function on all possible inputs, as you suggested, would immediately reveal a solution to the problem, which is undesirable. Right?

I think that testing if a sequence of properties hold could be a nice way to achieve to above goals in some exercises. In this case, here are some candidates, in a accidental order:

• Is the output horizontally symmetrical?
• Is the output vertically symmetrical?
• Is the shape a diamond filled with spaces?
• Are the sides ordered sequences of characters?
• Do they start with 'A'.
• Does the output have the expected size?

These are just examples. Again, I don't know what would be the recommended properties to be tested, and I'll probably not take the time to think about it soon.

[Average-user]

Ok, maybe I'll think about it.

[petertseng]

I understand that property-based testing seems like a strange choice for diamond because example-based tests can easily cover every possible input.

But I have little choice in the matter since that's what https://github.com/exercism/problem-specifications/blob/master/exercises/diamond/description.md and http://blog.ploeh.dk/2015/01/10/diamond-kata-with-fscheck/ say.

I now retroactively see that https://github.com/exercism/problem-specifications/blob/master/exercises/diamond/metadata.yml doesn't even list that link though; I got that link from exercism/problem-specifications#191 .

[rbasso]

I understand that property-based testing seems like a strange choice for diamond because example-based tests can easily cover every possible input.

I agree. While I think it would be interesting to find the minimal set of properties that define the solution, I'm not sure that would improve the user's experience, except for exposing students to property-based tests, which would be nice by itself.

But I have little choice in the matter since that's what https://github.com/exercism/problem-specifications/blob/master/exercises/diamond/description.md and http://blog.ploeh.dk/2015/01/10/diamond-kata-with-fscheck/ say.

Of course you do!

Please, never accept anything that you don't think would make the track better! 😄

Back to the subject, considering that we really don't have any exercise exclusively using property tests, instead of deciding a priori if this exercise should be property-based, maybe we could avoid the discussion until someone comes up with a concrete implementation. While I think that property-based testing is great, I lack the experience to determine in advance if they are a good idea in a specific case.

So I propose to close this issue until someone writes a well-polished implementation with QuickCheck, when the merits and drawbacks will be evident.

I now retroactively see that https://github.com/exercism/problem-specifications/blob/master/exercises/diamond/metadata.yml doesn't even list that link though; I got that link from exercism/problem-specifications#191 .

Thanks for the link, @petertseng!

[Average-user]

I'll try to implement this, I may take some time tho

[sshine]

Are you still interested in this problem, @Average-user?

I've lately begun adding property-based tests to other exercises.

I don't think the test is really worth the time spent in this one, but I don't think this should be the deciding factor for adding property-based tests. (I think the joy of making them + the potential for students to explore them is enough reason.)

[petertseng]

Back when diamond would have been the only non-deprecated exercise in this track that uses property-based tests, this would have been higher priority.

Since there are now other exercises with property-based tests, we could now reasonably ignore the recommendation of problem-specifications.

Consider whether the process of discovery such as the one chronicled in http://blog.ploeh.dk/2015/01/10/diamond-kata-with-fscheck/ would be useful to students

If not, I reread https://github.com/exercism/problem-specifications/blob/master/exercises/diamond/description.md and determined we're not in violation of the description if we don't add property-based tests, so closing this issue would be the only action we need to take in that case.

[Average-user]

@sshine Not very interested right now to be honest. Maybe some time tough

[sshine]

I'll close this issue for now, then. We can refer back to it when the interest arises.

[petertseng]

Good to close this now, right? Unless there is to be a discussion about any other tests that could be good to add