I can't say whether it is necessary or not; I test my ruby code
quite differently (and really sparingly) compared to many other
ruby hackers so I am not a good candidate to ask for any test
or assertion system/framework.
Some testing frameworks make use of ruby in interesting ways,
in my opinion.
Take RSpec:
expect(Dir.exist?('doc')).to be true
The:
.to be true
part surprised me the first time I saw it. :)
Python has doctest, I think, which is fairly minimal:
doctest.testmod()
Don't know how useful it is, though. If I recall correctly
then you wrote code in the function description. I personally
found it a bit weird, since I'd expect more normal text in
a description to a function/method.
To your suggestion - it may be that the ruby core team
expects some more context in how your proposal may be
used or how it may be useful; ideally compared to what
is already used, such as for the ruby specification itself
(the various test code of ruby; you can see these parts often
when you look at ruby git at https://git.ruby-lang.org/ruby.git/ -
the ruby dev team often writes test code in the .rb files).
I don't think there is any particularly high reason against
your proposal as such (not sure if it should reside on Kernel
or elsewhere, but I think this is a separate detail; the more
important question is how the suggestion in itself may be
sufficiently useful) - but the ruby dev team likes to have
some specific details or some specific use case. Higher priority
is usually given to when suggestions may solve existing problems,
so in my opinion it often helps a lot to detail these problems
or possible problems/pain points. (It also follows from the
ruby philosophy, see how various suggestions have been accepted
in the past when they referred to existing problems or constraints.)