Minitest, Test::Unit, and Rails

minitest, test::unit, and rails

There is a Test::Unit "compatibility" module that comes with Minitest, so that you can (presumably) use your existing Test::Unit tests as-is. This is probably the Test::Unit module you are seeing.

As of rails 3.2.3, generator-created tests include rails/test_help which includes test/unit.

The test "something" do syntax is a rails extension. It's defined in ActiveSupport::Testing::Declarative, which is require'd by rails/test_help.

Minitest and Test::Unit

Basically, Test::Unit got replaced by MiniTest (which ships with Ruby now). MiniTest tests can be written in the Test::Unit syntax or in the MiniTest::Spec syntax. Mini::Test, as a standalone, doesn't have a future... but MiniTest is faster, smaller, included by default, and has a great future and, IMHO, you should definitely make the switch! Although it is definitely lacking in documentation, as you have found. For the most part, you can just use Test::Unit documentation for help with using MiniTest.

What does this MiniTest::Unit::TestCase warning mean?

You must have upgraded to minitest 5.0. MiniTest::Unit::TestCase was renamed to Minitest::Test. Here are the release notes.

How to run MiniTest::Unit tests in ordered sequence?

You can use i_suck_and_my_tests_are_order_dependent!() class method.

class MyTest < MiniTest::Unit::TestCase
  i_suck_and_my_tests_are_order_dependent!   # <----

  def test_1
    p 1
  end

  def test_2
    p 2
  end
end

But as the name suggest, it's not a good idea to make the tests to be dependant on orders.

How to organize minitest/unit tests?

I know several folks coming from RSpec to minitest struggling with the same question. They love the ability to nest using describe/context blocks and want to continue in minitest. There are several solutions:

1. Use minitest's spec DSL: While there are minor differences, the spec DSL gives you most (all?) of the good parts of the rspec DSL. The big difference is the lack of context blocks. But you can just as easily use describe in its place and everything works as you'd expect.
2. Use directories and files: I prefer this option. I dislike scrolling through a 300 line test file, regardless whether its using the spec DSL or the classical xUnit style. I do not find nesting unrelated tests helpful. The same rules for comprehension for code applies to tests. So break it up. Create a directory and place several files within it.

Here is an example of how my test files are organized:

test/
     models/
            user/
                 authentication_test.rb
                 email_test.rb
                 reservation_test.rb
                 user_test.rb
                 username_test.rb

I use this structure whether I'm using the spec DSL or the xUnit style. When using the spec DSL I specify what I'm testing in my describe block like so:

require "minitest_helper"

describe User, :authentications do

  before do
    # ...

Ruby: Minitest, test-unit and instance variables

At least in Minitest you can safely do, for example,

setup do
  @form = Form.new
end

without @form getting mixed up between parallel tests, so this approach should be safe too:

def setup
  @stat = m
  @pid = n
end

which means that your original approach should be safe as well.

================

UPDATE

consider the following gist with a piece of code that define 100 different tests accessing @random which is set in setup https://gist.github.com/bbozo/2a64e1f53d29747ca559

You will notice that the stuff set in setup isn't shared among tests, it is run before every test, basically every test is encapsulated so thread safety isn't an issue.

---

Related Topics