In other languages, there seems to be a test for checking the distribution of values for the Ability() function. See Here.
In the Go tests, it only checks that it returns a value within range. I noticed some of the submissions wouldn’t ever return an 18, so my function just returns 3 every time. Should we write a test for checking that at least all values are hit in the 1000 times it runs, if not a distribution check?
Most tracks don’t do this ;) But that doesn’t mean Go shouldn’t do this.
I think it would be an improvement to the exercise for sure. I’m happy to make a pull request, could you guide me on the proper way to go about it? This would be my first attempt and it looks like you’re an old pro!
You’ll first need approval from a Go maintainer.
I’m aware of a few tracks that create X number of characters, checking each time that at least one of the abilities changed from the previous character. Checking the distribution of ability scores is testing how the ability score is generated, and that’d be an implementation detail.
If the goal of the exercise is to simulate the outcome of rolling 4d6 and taking the highest 3 as the total, then the implementation should have outcomes that mirror the possible outcomes, right? I believe it is unhelpful if an exercise marks a solution as complete that doesn’t satisfy the requirements. See this solution
I agree that a specific implementation (or, distribution) is expected here.
I don’t think this is the type of random result we should accept.
I think we had the discussion about adding testing for randomness often enough in the forum. I hope to summarize the issue correctly:
Did I miss something?
I think these are decent points in general, but perhaps less of a concern for this particular case?
When pulling a random number from 15 possibilities, the generally expected number of pulls to get one of each is about 50. With the way the test stands now, it checks 1000 times (which, if we’re not checking for distribution or even change, why run it more than once?) so it would be an incredibly rare event not to see all 15 possibilities (about 7.4×10^−29). If someone were to have an implementation closer to the expected outcomes of dice (not evenly distributed) it would still be astronomically unlikely.
In regards to the last point, I do agree. However, that argument could be used to justify having no tests at all. After all, if someone does the exercise wrong, they’re only hurting themselves and their own learning experience.
In any case, even just testing that the value changes would be an improvement. However, it may just be good enough as is, I just figured I’d ask. Thank you for your reply!