Looking into using Minitest for an existing Rails 3.2.
I'm trying to understand the difference between minitest-rails and minitest-spec-rails.
The main differences between minitest-spec-rails and minitest-rails is the scope of the problems they solve.
minitest-spec-rails
minitest-spec-rails overrides the test infrastructure that Rails provides by default and adds the ability to use the Minitest Spec DSL and matchers in your tests. This means that you don't have to make any changes to your existing tests to start using the Spec DSL. It also means that the Spec DSL is available in every test.
minitest-rails
minitest-rails adds the ability to use the Spec DSL, but also changes the approach to how tests are written. It provides new generators for your tests, and allows you to choose from the TDD-style assertions or the BDD-style expectations. It places test files in more sensible locations.
It also allows your existing tests to live side by side with your new Minitest tests. You have the option to override the default test infrastructure similar to minitest-spec-rails, but you also have the option to leave them untouched.
Disclosure: I am the author of minitest-rails
With minitest-spec-rails, we have a working solution by replacing MiniTest::Spec as the superclass for ActiveSupport::TestCase. This solution is simple and does not require you to recreate a new test case in your test_helper.rb or to use generators supplied by gems like minitest-rails.
Minitest changes for testing within Rails. Your test classes will inherit from MiniTest::Rails::ActiveSupport::TestCase a opposed to ActiveSupport::TestCase. You can use the MiniTest::Spec DSL. You can generate test files with the standard model, controller, resource, and other generators.
rails generate model User
or
And you can specify generating the tests using the MiniTest::Spec DSL on any of the generators by providing the --spec option
rails generate model User --spec
Related
In rails configuring guides, https://edgeguides.rubyonrails.org/configuring.html#configuring-rails-components, under section 3.3, there are a list of methods that can be used in config generators block. Among them are system_tests and test_framework, which are defined as follows:
system_tests defines which integration tool to use to generate system
tests. Defaults to :test_unit
test_framework defines which test framework to use. Defaults to false
and will use minitest by default.
The question is what's the difference between them, cause integration tool and test framework are both synonyms for me. Besides test_unit and minitest, based in my researchs on Google, are both test frameworks, and minitest is kind of a test_unit replacement.
You migth also have noted that in test_framework definition is written: "Defaults to false and will use minitest by default". The only left question is, what?!!!
If it defaults to false, shouldn't it mean that no test framework will be used? This assertion is completely illogical.
I agree, it is confusing how they write it.
I think when they say "system test," they are referring to the popular "integration tests" or "feature tests" which as you know, interacts with the browser. So they're saying they will use test unit which will probably use capybara driver under the hood.
I think when they say "test framework," they are saying you could use something like rspec to write your tests instead of minitest.
It will probably help if you think of integration tool as the under-the-hood driver such as capybara.
Sorry I'm on mobile app and cannot see rest of your question so I will submit then update if needed.
Is there a difference between a feature spec and system spec? Both seem to use Capybara to test the full application yet they have different docs on RSpec.
System specs are built on top of Rails own system tests while feature specs were implemented by RSpec before Rails had system tests. If you're starting a new project write system specs, but if you have existing feature specs there's really nothing to be gained currently by changing them to system specs since functionality wise they're basically identical.
In my cucumber step definitions, I want to use constants defined in "#{Rails.root}/config/initializers/constants.rb" and FactoryGirl factories defined in #{Rails.root}/spec/support/factories". How do I configure cucumber to look in those places?
Files in the initializer are loaded automatically when the Rails application starts. The same applies to factories, as long as the factory_girl_rails is added as dependency to the environment that is used by cucumber to run the scenarios (generally cucumber).
I notice after reading the rails guide docs
that minitest comes with the newer Ruby versions out of the box, so it's available right away, no need to install anything else. Rails 4 by default use that.
If fact i use the minitest-reporter gem and it work like charm.
The confusion comes when i see examples defining the :test group of the gemfile like this:
group :test do
gem 'minitest-rails'
gem 'minitest-rails-capybara'
gem 'minitest-colorize'
gem 'minitest-focus'
end
Why is the need of include a minitest-rails gem ?? To use some rails generation later or other kind of specs ??
I'm kinda confused here so any thought about Rails 4 Minitest integration will be appreciated.
According to the mini-test rails README, it makes it so Rails generators for tests will generate in minitest style. It also makes it so minitest style actually works in Rails ActiveSupport::TestCase test classes. (which is what Rails test cases do).
minitest comes with ruby, but the Rails' ActiveSupport::TestCase, which Rails test classes all are, doesn't normally use minitest. minitest-rails makes it so it does.
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. You can generate test files with the standard model, controller, resource, and other generators:
https://github.com/blowmage/minitest-rails
One thing that makes this more confusing, is that in newer versions of ruby [i accidentally said 'Rails' before, but it's newer versions of ruby that matter], it's true that Minitest is there and old Test::Unit is not. But Minitest has a sort of "pretend to be Test::Unit" mode -- that's what Rails ActiveSupport::TestCase ordinarily uses, the old Test::Unit style of testing -- even if it's actually the minitest library providing it. minitest-rails makes it support the newer Minitest::Spec::DSL style.
minitest-rails is already a dependency of minitest-rails-capybara which you are using and have added to the test group.
So regardless of whether you explicitly add minitest-rails to the Gemfile or not, it will be installed for your application. However, you might wish to explicitly specify a specific version of minitest-rails that you want to use, and in such case you should add the gem to your Gemfile with the wanted version (something you are not doing in your code).
If you have no interest in using Minitest's spec DSL then you don't need to include minitest-rails. If you have no interest in Capybara's spec DSL then you don't need to include minitest-rails-capybara, although if you want to use Capybara you will need some other mechanism to add it to your application. The minitest-capybara gem doesn't do any rails integration.
It is possible that these two libraries are added to add the Capybara support even though you use test style tests and not spec style tests. The minitest-rails-capybara gem adds generators for Capybara tests in both test style and spec style. Try git blame on your Gemfile to find the commit where those two lines were added, as the commit message might explain why they are in the application.
I want to write acceptance testing through cucumber and capybara. i have experience with rspec. I want to write integration/features test cases . I want outcome to be seen on a web browser which shows the test case running. what are the gems required for writing test cases .
If you are already familiar with RSpec, I recommend you to use RSpec with Capybara for acceptance testing. RSpec is testing framework, and Capybara is a library that helps you to test web applications by simulating how a real user would interact with your app.
Acceptance tests in RSpec with Capybara are called "feature specs" and live in /spec/features directory in Rails. Capybara comes with a built in DSL for writing descriptive acceptance tests with RSpec (feature/scenario), but you may also use traditional RSpec DSL (describe/it).
Capybara supports several drivers, and its default driver RackTest doesn't support JavaScript. So, probably, you'll want to use one of the alternative drivers (I prefer Poltergeist, but it is headless, so if you want to see result in the browser, you may use Selenium driver). In this case, you'll need to set up database_cleaner to clear your database between tests. Capybara's README contains a lot of information about its configuration and usage with RSpec, configuring driver and using database_cleaner.
You can start with this and this screencasts. But remember, that they are a little bit outdated and use traditional RSpec DSL (instead of new Capybara DSL), and use old convention, when "feature" specs were called "request" specs. Currently, by convention, "request" specs, are integration tests without capybara. So you'll need to create your capybara specs in spec/features directory, not spec/requests. And if you want to use Capybara DSL, this is easy to fix too. Just replace describe with feature, it with scenario, let with given etc. It is well documented in Capybara's README.
Hope this helps.