>"Sometimes, you can get different results by calling the method without a
>receiver (what you do in this testing infrastructure)"

Well, it might be a matter of wording, maybe I'm not quite getting what
you say (English is not, after all, my mother tongue), but I totally
fail to see why you think methods get called without a receiver inside
TeSLa. As far as my understanding of what a receiver is, they don't. In
line 31 of tesla.rb you can see the following
	@instance = self.new
self being the class where the tests are being defined. Later on,
inside method #assert (line 105 to be precise) you find the following
	result = @instance.send(@method_name, *@params)
As you can see, there's no eval_ing of the method being tested, the
method is being sent to a previously created instance of the class in
which both the test and the method being tested are defined. It's true
*right now* you can directly test private methods, but that is
intentional, as the inability to test private functionality is a common
complain from people using other testing frameworks, and as such,
something I wanted TeSLa to offer. Also, testing a private method will
always end up in the private method being called, regardless of
#method_missing being defined in the class or not. I stressed *right
now* because in Ruby 1.9 you can't use Object#send with private
methods, so as it's currently implemented TeSLa won't be able to do
that. By the time Ruby 1.9 is out (in a stable form, that is) I'll be
forced to either create an explicit syntax for doing tests on private
methods of trying to work some inner magic with the newly introduced
Object#funcall.
By the way, the only thing that gets eval_ed in TeSLa are the
Test::Unit test methods, but that's only because I want to rely on
Test::Unit reporting and tool integration. If TeSLa were to do its own
test report (which by the way it does, only it's commented out) there
would be no evals in the code.