Can't get output from MiniTest

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

Hi,

On Wed, Nov 12, 2008 at 5:37 AM, David A. Black [email protected]
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.

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

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?

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… :slight_smile: 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

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

On Nov 12, 2008, at 10:23 , Dave T. wrote:

explicit require for autorun behavior:

What do you guys think?

(As you know… :slight_smile: 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.

On Sat, Dec 13, 2008 at 1:14 PM, Ryan D. [email protected]
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).

  1. 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?

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.