Sync triangle with problem-specifications #1816
Conversation
There were two challenges implementing the test template. The problem specification of this exercise states that it is up to the individual language tracks how to handle invalid triangles and whether or not to include the floating point cases. However, neither of these two properties are easy to detect from the specification of the test cases. In order to be able to feature-gate the floating point tests, the word "float" is detected in the test case description. This is not perfect, but likely robust enough, even if there are more such tests in the future. For the invalid triangles, there is no way at all to detect them from the specification. These test cases had to be excluded in tests.toml and reimplemented in additional-tests.json with a custom property of "invalid". It was also necessary to separate the different properties into individual modules. Some descriptions - and therefore the generated test case names - are duplicated across different properties, so they have to be in different namespaces.
|
In general, the previous test suite seems to have drifted pretty far from problem-specifications. I have noticed two test cases from the previous suite that are now missing, they test whether invalid triangles with floating-point sides are handled correctly. Such a test case does not exist in problem-specifications. I couldn't think of a case where invalid integer triangles are handled correctly, while invalid floating-point triangles are not, so I think these tests don't provide any value. If I'm missing something and they do provide value, they should probably be upstreamed instead of added to The commit introducing these tests on the Rust track state:
So it seems like the original author also didn't have a concrete scenario in mind where these test cases might provide value. |
Maybe it would be worth adding the |
|
Sorry this slipped under the desk a bit. Thanks for suggesting the scenario, I wasn't aware of that feature in |
There was one challenge implementing the test template. The problem specification of this exercise states that it is up to the individual language tracks how to handle invalid triangles. However, this property is not easy to detect from the specification of the test cases. The test cases with invalid triangles were excluded in tests.toml and reimplemented in additional-tests.json with a custom property of "invalid".
It was also necessary to separate the different properties into individual modules. Some descriptions - and therefore the generated test case names - are duplicated across different properties, so they have to be in different namespaces.