what is the difference between using Minitest::Spec and ActiveSupport::TestCase in my test_helper in Rails 4?
This project aims to enable MiniTest within the Rails TestCase
classes. Your test will continue to inherit from
ActiveSupport::TestCase, which will now support the spec DSL.
Minitest on Github
This means you don't have to use Minitest::Spec and can simply use ActiveSupport::TestCase all the time to get some convention in your code.
Edit: When you don't use minitest-rails gem you have to register_spec_type
class ControllerSpec < MiniTest::Spec
end
# Functional tests = describe ***Controller
MiniTest::Spec.register_spec_type( /Controller$/, ControllerSpec )
I've never actually used anything besides rspec, but according to their public APIs, ActiveSupport::TestCase only supports testing if an error was raised, while Minitest::Spec has a bit more support for testing things other than succesful DB queries.
Related
Can I define all of my stub methods at one place instead of defining them in each test case?
For example i have this piece of code
SocialNetworks::Facebook.any_instance.stubs(:update_status).returns(true)
in multiple test cases. But if I move it in test_helper.rb file then running test cases won't work.
Does mocha gem allowed to place these stubs at one place?
I am using rails Minitest for testing rails app. And mocha gem for
stubing and mocking.
You can do that in setup callback, like:
class YourTest < ActiveSupport::TestCase
setup do
SocialNetworks::Facebook.any_instance.stubs(:update_status).returns(true)
end
end
setup is called before each test case.
I usually write my specs in RSpec but I use Minitest too.
Recently I learnt that there is a minitest dsl that could read like RSpec. They call it Minitest::Spec. I have checked it out and I think I like it. The gem 'minitest-rails' makes the setup configuration easy. There is however one limitation I have faced and that is in the integration specs. What is the equivalent for assertions like assert_response, assert_no_difference, and assert_template?
I have seen an answer. It turned out that I got them in the very gem that supplied the test expectations. I looked into the source code of the minitest/rails/controller.rb and I saw the simple way those expectations were implemented is by aliasing the real minitest assertions. Here is my find
class ActionController::TestCase # :nodoc:
alias :must_respond_with :assert_response
alias :must_redirect_to :assert_redirected_to
alias :must_render_template :assert_template
alias :must_select :assert_select
alias :must_select_email :assert_select_email
alias :must_select_encoded :assert_select_encoded
end
I have two questions. The first is a basic one. MiniTest is a drop-in replacement for UnitTest. So if you use generators in rails, you get a bunch of ActiveSupport::TestCase classes. If you use minitest (without minitest-spec-rails) then you can do
1.must_equal 1
# instead of
assert_equal 1, 1
Correct? So it's confusing to me why there's a MiniTest::Unit::TestCase class as described in railscast #327 (pro episode paywall sry). It's confusing when looking at a test suite which I'm actually using. If minitest is a drop-in replacement then I'm using minitest to execute testunit style rails tests. If I take it out, I'm using testunit to run testunit tests?
So let's say I am using MiniTest to run TestUnit style tests.
require 'test_helper'
class FooTest < ActiveSupport::TestCase
end
After watching destroyallsoftware's screencast on extracting domain objects, I was inspired. He makes some good points about avoiding loading test_helper.rb to speed up the test suite without resorting to spork trickery (which is exactly what I do). But how can I avoid loading test_helper.rb when that's what gives me ActiveSupport::TestCase from above?
Can you not extract domain objects and put them in lib/ or extras/ with MiniTest or TestUnit?
The answer to your first question is "no, not correct". Minitest is not a "drop-in replacement" for Test::Unit. Minitest provides a simpler implementation for most of Test::Unit, but not all of it. In Ruby 1.9 the Test::Unit library is built on top of Minitest's TestCase class, and fills the gaps between the two libraries.
Minitest provides two modes for writing tests: the classic TestCase approach, and a separate Spec DSL. Like Test::Unit, the Spec DSL is built on top of Minitest's TestCase. So while 1.9's Test::Unit and Minitest's Spec DSL are both are built on Minitest's TestCase, you can't use the Spec DSL in Test::Unit because its not part of its ancestry.
The answer to your second question is you cannot avoid test_helper.rb if you want to use ActiveSupport::TestCase. You will need to require minitest/autorun and have your test class inherit from MiniTest::Unit::TestCase.
When I started my Rails app, I chose RSpec as my testing framework, because of all the hype. Now, I'm trying to write more tests, and I find that I don't like to write tests this way. I'd like to switch back to the default testing framework.
How could I do this switch? I'm using Rails 3.0.5
Don't know if you are aware, but if you use assertions instead of rspec-expectations (obj.should matcher), which you can already do without any additional configuration, then the only difference is this:
# w/ Test::Unit
class FooControllerTest < ActionController::TestCase
test "something or other" do
...
end
end
# w/ RSpec
describe FooController do
it "does something or other" do
...
end
end
Everything else that you can write using Test::Unit in Rails, you can write using RSpec exactly the same way.
Then you get all the non-syntax-related benefits of RSpec like readable output, a robust command line tool with its own -help output, etc.
I realize that doesn't answer the question you're asking, but I hope it helps you in your decision process.
It's not an either/or situation. You can have RSpec and Test::Unit tests in the same Rails application, so just begin writing Test::Unit tests. No need to switch, just do new development with Test::Unit.
Depending on how you run your tests, your CI setup, and how you have modified your app this may be more or less changes, but in practice these are straightforward.
in config/application.rb
module AppName
class Application < Rails::Application
generate.test_framework :test_unit, :fixture => false # :rspec <- before
...
New models/controllers generate the basic test/* files
I keep getting validation errors when running factories due to uniqueness constraints on fields. I am using shoulda with factory_girl. I have a both a unit test and a functional test creating 2 products in the database. I can run 'rake test:units' and 'rake test:functionals' over and over in any order and everything is will be green but when I run 'rake test' which runs the units followed by the functionals I get errors due to uniqueness.
I also tried creating models to break uniqueness in 2 different unit tests and I get the error then as well.
I have been playing with these settings in test_helper.rb but can't get anything to work
class ActiveSupport::TestCase
self.use_transactional_fixtures = true
self.use_instantiated_fixtures = false
end
Does the transactional_fixtures setting take any effect of factories. Whats the best way to handle cleaning the database between tests?
(sigh..)
So the problem was that I was copying code from the shoulda docs and ended up declaring my test classes like so:
class UserTest < Test::Unit::TestCase
However for the transactional fixtures setting to have any effect you need to inherit from ActiveSupport::TestCase by declaring your classes
class UserTest < ActiveSupport::TestCase
Hopefully this can help save someone else some time.