armstrong-numbers: Inaccurate test/description

[srbry]

The armstrong-numbers description of There are no 2 digit Armstrong numbers and the test data of 10 don't quite line up. The tests would happily pass if 11 was detected as an armstrong number even though it would be incorrect.

https://github.com/exercism/problem-specifications/blob/ca9c09eda445e642317a043bf9c949fbffae4020/exercises/armstrong-numbers/canonical-data.json#L14-L20

I would suggest that the ideal solution is to actually have tests that assert on the entire range of 2 digit numbers to make the tests accurate to the description, although the simplest possible thing might be just adjusting the description to be more specific to the test case. Two digit number that is not an Armstrong number

[rpottsoh]

I would not be opposed to a change along these lines to the description. Delphi currently loops through all two digit numbers and asserts that isArmstrongNumber(i) is false. The only issue I see with a change like this is we are dismissing the fact that there are no 2 digit Armstrong numbers. It will only claim that particular instance is not an Armstrong number. But then how important is it to inform that there are no two digit Armstrong numbers?....

[srbry]

I am not strongly opinioned either way, although I was directed here through https://github.com/exercism/python/pull/1739 where I was attempting to add a loop within the Python track to do the same check as it sounds like Delphi is doing.

I guess as this is training material my question is: Are we trying to just teach coding or teach the importance of quality tests?

If we are trying to teach quality tests than actually asserting on the "customer" outcome is probably important.

If we are just trying to teach some basic algorithms then the single case of 10 that exists is probably sufficient.