Not a bad idea since a lot of the problems on this challenge are not people coding it incorrectly, just differently. I don’t think any of the alternative solutions I’ve tested are longer, more inefficient, or less “pythonic” than the expected one.
Either a warning, or increase the iterations (which should push the computed value closer to 0.263) and/or widen the tolerances around the actual value to include any/most/some good solutions. The curriculum doesn’t really cover the fact that these random number generators are really psuedo-random number sequences and the unit test is tied to a very (too) specific way of solving the problem (i.e. a certain n psuedo-random numbers).
I am slightly interested in what would happen if the system’s cryptographic number generator was used instead and if there would be any measurably faster convergence so that the test could remain tightly constrained but there would be less impact from coding it a certain way.