Add dnd_character exercise based on 48in24 implementation status page: https:/exercism.org/challenges/48in24/implementation_status
Yes please 
@iHiD here’s the PR, forgot it on the original comment 
Add dnd_character exercise by mr-sigma · Pull Request #1629 · exercism/ruby · GitHub
The tests ruby/exercises/practice/dnd-character/dnd_character_test.rb at main · exercism/ruby · GitHub pass even if you ignore all the dice rolling/random instructions and just return a fixed value for each ability.
I believe that’s pretty typical for this exercise. There’s no canonical test case for that in the upstream problem-specifications repo that Exercism tracks share.
Did you have something in mind? For example, some tracks add an additional test that creates a character X times and checks that at least one attribute changes each time.
@BNAndras unless assumptions can be made about exactly how the random numbers are generated (so it can be stubbed in a test), there’s no definite way to test that randomness has been used at all.
I’m more concerned that a decent chunk of the instructions cover how to calculate the values for the abilities, but that is never tested, so a user could implement it wrong and the tests will still pass (meaning an opportunity for learning is missed).
perhaps the tests could assert a result on a named method that takes the raw dice roll values as arguments and returns the calculated ability value .
@tomcol The exercises usually do not restrict students to implement certain “inner structures or behaviours” just to ensure people do not cheat. Not implementing the requested behaviour is only hurting your own learning experience, and preventing cheating is very much harder than most people think.
We want discussions about the inner workings in the mentoring phase, do not try to cover all edge cases (or cheating) with tests and have as much freedom to implement solutions as possible. Sometimes this makes it very easy to cheat (like here), but most people actually do implement the requested behaviour.
This is really a different topic and should not be in this thread.
That said, it is not likely that testing for randomness is something that I would do. We test more fully a randomized solution where at least some tracks check that their random functionality is used, and some of them use a seed to ensure a known sequence, and many of them test a full set of possibilities as well.
This idea can come out in mentoring, and hopefully does when someone does not more fully explore the Troll or Roll language ideas, or at least shows some thoughts for doing what is asked. But testing for the diverse ways in which someone can put this together, using different ideas, such as object oriented programming, procedural programming, functional programming, all legitimate approaches in Ruby, it is not required for success for the learning potential of this exercise and its correctness of functionality.
There are also metaprogramming aspects of this exercise that are possible (and pretty likely) and I focus more on these as well, during mentoring.
I would not bring up cheating, as if the tests pass, then it is solved. (And who is cheated? Perhaps no one, and perhaps someone even learned something by it, which is the actual goal, and therefore the “cheat” really never even happened.)
The learning is in the doing, even if how it is solved may not be as described. The discussion can be had and the student can choose to take a different direction.