Forum: Ruby Can't get output from MiniTest

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
David A. Black (Guest)
on 2008-11-12 15:41
(Received via mailing list)
Hi --

I feel like a lamb to the slaughter, since I'm almost certainly doing
something obviously wrong, but I'm having trouble understanding why
I'm not getting any output from this:

require 'minitest/unit'

class TestMe < MiniTest::Unit::TestCase
   def test_something
     assert(true)
   end
end

Here's what happens when I run it with a recent 1.9:

david-blacks-macbook:hacking dblack$ ruby mini.rb
david-blacks-macbook:hacking dblack$

In other words, nothing. If I change mini to test, it does this:

david-blacks-macbook:hacking dblack$ ruby mini.rb
Loaded suite mini
Started
.
Finished in 0.000676 seconds.

1 tests, 1 assertions, 0 failures, 0 errors, 0 skips

I've probably just missed a beat in how to make the transition. Thanks
for any help.


David
John B. (Guest)
on 2008-11-12 19:32
(Received via mailing list)
Hi,

On Wed, Nov 12, 2008 at 5:37 AM, David A. Black 
<removed_email_address@domain.invalid>
wrote:
> end
Minitest doesn't install an at_exit hook by default. I think the
expectation is that Rake tasks, test helpers, or other project
infrastructure should activate the autorun magic explicitly. If you
want to have tests in a single file run as they would in test/unit,
adding this at the top should help:

MiniTest::Unit.autorun


~ j.
David A. Black (Guest)
on 2008-11-12 19:34
(Received via mailing list)
Hi --

On Thu, 13 Nov 2008, John B. wrote:

>>  def test_something
> MiniTest::Unit.autorun
Thanks -- that's the missing piece of the puzzle.


David
Ryan D. (Guest)
on 2008-11-12 19:59
(Received via mailing list)
On Nov 12, 2008, at 09:31 , David A. Black wrote:

>> Minitest doesn't install an at_exit hook by default. I think the
>> expectation is that Rake tasks, test helpers, or other project
>> infrastructure should activate the autorun magic explicitly. If you
>> want to have tests in a single file run as they would in test/unit,
>> adding this at the top should help:
>>
>> MiniTest::Unit.autorun

I've been talking to both John and Dave T. about this
(separately). Currently minitest/unit.rb is analogous to test/unit/
testcase.rb, not test/unit.rb and I really like it that way. It means
I can finally write abstract testcases w/o autorun side effects (and w/
o the undef_method madness from test/unit). But, I agree that the
current situation is confusing and less than ideal. I think the
simplest thing that could possibly work is to have an explicit require
for autorun behavior:

# minitest/autorun.rb:

require 'minitest/unit'
require 'minitest/spec'
require 'minitest/mock'

MiniTest::Unit.autorun

---

What do you guys think?
Dave T. (Guest)
on 2008-11-12 20:27
(Received via mailing list)
On Nov 12, 2008, at 12:55 PM, Ryan D. wrote:

>
> require 'minitest/unit'
> require 'minitest/spec'
> require 'minitest/mock'
>
> MiniTest::Unit.autorun
>
> ---
>
> What do you guys think?

(As you know.. :) I'd vote for autorun being the default, as most
people use it, and making it possible to disable autorun when you
define the tests.


Dave
Ryan D. (Guest)
on 2008-12-13 02:39
(Received via mailing list)
On Nov 12, 2008, at 10:23 , Dave T. wrote:

>> explicit require for autorun behavior:
>>
>> What do you guys think?
>
> (As you know.. :) I'd vote for autorun being the default, as most
> people use it, and making it possible to disable autorun when you
> define the tests.

after careful consideration, I decided against this. One of Jeremy
Kemper's latest bugs (on ruby 1.9) was the final straw. I weighed the
pros and cons of going with your idea of having a special superclass
construct to disable autorun for abstract testcases, and that was
finally rejected because it wasn't the simplest thing that could
possibly work. I finalized (as finalized as I ever get at least) on
'minitest/autorun.rb' as the simplest thing that could possibly work.
It is already in ruby trunk and will go out in the next release of
minitest. (I should point out that I only did the first require, not
spec or mock).

It just makes much more sense to me from a design perspective.
Joshua B. (Guest)
on 2008-12-13 20:25
(Received via mailing list)
On Dec 12, 2008, at 7:31 PM, Ryan D. wrote:

>>> effects (and w/o the undef_method madness from test/unit). But, I
>>> MiniTest::Unit.autorun
> Kemper's latest bugs (on ruby 1.9) was the final straw. I weighed
> the pros and cons of going with your idea of having a special
> superclass construct to disable autorun for abstract testcases, and
> that was finally rejected because it wasn't the simplest thing that
> could possibly work. I finalized (as finalized as I ever get at
> least) on 'minitest/autorun.rb' as the simplest thing that could
> possibly work. It is already in ruby trunk and will go out in the
> next release of minitest. (I should point out that I only did the
> first require, not spec or mock).
>
> It just makes much more sense to me from a design perspective.

Quick question from the unwashed masses: I admit I have not been
following along closely, but is there a reason that 'testrb' wouldn't
be moved from test/unit to minitest/unit?

- Josh
Ryan D. (Guest)
on 2008-12-13 21:22
(Received via mailing list)
On Dec 13, 2008, at 10:17 , Joshua B. wrote:

> Quick question from the unwashed masses: I admit I have not been
> following along closely, but is there a reason that 'testrb'
> wouldn't be moved from test/unit to minitest/unit?

um. this got kinda big. sorry.

1) a small (semantic) correction: nothing was moved from test/unit to
minitest as minitest was implemented from scratch.

2) I implemented only what I found to be the essence of test/unit and
really that was the testcase public api and a very simple runner. I
went with subclassing as the only testcase discovery mechanism because
that works better for junit and rubinius (because
ObjectSpace.each_object is a PITA).

3) I didn't see any point in testrb. Indeed I forgot about it until
reminded. I've never once used testrb in my normal process nor has
anyone I've ever paired with. (Well, to be honest, I tried a couple
times back in the day, didn't get it to work for me, and ignored it
from then on). I've pretty much always run my tests via autotest,
rake, or just straight up (usually in that priority order).

4) Tests are just ruby. They should run the same way that anything
else you write in ruby runs: with the ruby interpreter. I really
dislike systems like rspec and mspec that require a runner script to
work. They're harder to use, hook, debug and generally have way more
"stuff" than I ever want to deal with.

In short: "Do the simplest thing that could possibly work" should
apply to more than just the code.
David C. (Guest)
on 2008-12-16 16:55
(Received via mailing list)
On Sat, Dec 13, 2008 at 1:14 PM, Ryan D. <removed_email_address@domain.invalid>
wrote:
> minitest as minitest was implemented from scratch.
> pretty much always run my tests via autotest, rake, or just straight up
> (usually in that priority order).
>
> 4) Tests are just ruby. They should run the same way that anything else you
> write in ruby runs: with the ruby interpreter. I really dislike systems like
> rspec and mspec that require a runner script to work. They're harder to use,
> hook, debug and generally have way more "stuff" than I ever want to deal
> with.
>
> In short: "Do the simplest thing that could possibly work" should apply to
> more than just the code.

How about The Principle of Least Surprise?
This topic is locked and can not be replied to.