Can't get output from MiniTest

[David A. Black]

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

 

[John Barnette]

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

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]

Hi --

Hi,



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

Thanks -- that's the missing piece of the puzzle.


David

--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL
Advancing with Rails January 19-22 Fort Lauderdale, FL *
* Co-taught with Patrick Ewing!
See http://www.rubypal.com for details and updates!

 

[Ryan Davis]

I've been talking to both John and Dave Thomas 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

 

[Dave Thomas]

I've been talking to both John and Dave Thomas 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

(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 Davis]

(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 Ballanco]

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.

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 Davis]

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 Chelimsky]

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.

How about The Principle of Least Surprise?