Conversation
ErikSchierboom
left a comment
ErikSchierboom
left a comment
There was a problem hiding this comment.
This also raises the question: How are new optional test cases handled if they require an addition to the description?
I don't understand this. Addition to what description?
| }, | ||
| { | ||
| "uuid": "bd1eab16-7603-4a77-ae4e-23c930fe39cd", | ||
| "description": "Ordering", |
There was a problem hiding this comment.
I don't have a better alternative, but this description is fairly minimal. Maybe something like Rational numbers can be ordered or something like that?
There was a problem hiding this comment.
The name is in the style of the other names, like "absolute value" or "multiplication". Do you think it should be longer anyway?
There was a problem hiding this comment.
There is some inconsistency in the test naming. I'm fine with keeping it as is therefore, but let's see what others think.
| { | ||
| "uuid": "bd1eab16-7603-4a77-ae4e-23c930fe39cd", | ||
| "description": "Ordering", | ||
| "property": "<", |
There was a problem hiding this comment.
In the diffie-hellman exercise, we experimented with using a textual description of the property. This might be useful here too.
There was a problem hiding this comment.
Interesting, didn't know about that exercise. Do you think that format would be better here? I feel like it'd need special handling in generators either way, so I'm not sure if a description like in diffie-hellman has an advantage? It would likely need the comment anyway for extra explanations.
There was a problem hiding this comment.
It would definitely need the comment. I do think a textual property might be somewhat easier to understand. What do you think @SleeplessByte?
There was a problem hiding this comment.
Special handling is required either way (see linked-list); I think written out properties are more consistent with the other exercises.
Wouldn't care here 🤷🏽♂️🤗
SaschaMann
left a comment
SaschaMann
left a comment
There was a problem hiding this comment.
(the app won't let me add a single comment)
The addition to the description.md. If one chooses not to implement this new test case, they'd have a pointless explanation in the description.md file regardless. Or am I missing some tooling that removes that? |
|
No we don't yet have a way to elegantly handle this. |
|
@SaschaMann Are you still interested in working on this PR? |
|
No but if anyone wants to pick it up, feel free. |
|
Should we have a "Available for pickup" label created for issues like these? @ErikSchierboom @iHiD |
4 participants
This is a fun one, because I can't think of any sensible way to represent this in JSON. Therefore the test data is described in a comment. Testing only specific order operations would require adding dozens, possibly hundreds, of tests to cover all cases, so I don't think that's a feasible way of adding it to the canonical data.
An example implementation can be found on the Julia track.
This also raises the question: How are new optional test cases handled if they require an addition to the description?