Remove "integration" from testing

[blowmage]

Rails 4 has replaced the "unit" and "functional" names for tests and instead named the tests by what is being tested (models, controllers, helpers, etc). This pull request aims to continue that change by removing the name "integration" from the test classes and locations.

This pull request is a continuation of #7878. Instead of renaming "integration" to "acceptance", they are renamed to "requests".

attn: @spastorino, @tenderlove

[guilleiguaran]

@blowmage iirc, there isn't a consensus yet about the name of those tests

/cc @jeremy

[blowmage]

@guilleiguaran Yep, but we weren't moving closer to a resolution on the mailing list, so I thought I'd open a pull request. I'm happy to update the PR if a better name than "requests" can be agreed upon.

[josevalim]

I would stick with integration. I don't see a reason for changing if requests is all we can come up with.

[steveklabnik]

Well, the move is to change the naming from 'what kind of test is it' to 'what is it testing?' 'integration' is about the level of the test, and the parts of the stack you're exercising. Having 'integration' and 'model' tests are weird, having 'integration' and 'unit' tests makes sense, having 'request' and 'model' tests makes sense.

[rodrei]

I believe @steveklabnik has a good point.

[guilleiguaran]

Using the point exposed by @steveklabnik, I think that 'system' is a better answer to the question 'what is it testing?'

[steveklabnik]

The reason to stick with 'request' is that this is what RSpec calls them. That said, I'd support 'system' too.

[blowmage]

I desire a concensus around a replacement for "integration", whether it be "requests" or something else. The viable options from the previous discussion are:

• requests
• systems
• resources

The reasons I think "requests" makes the most sense is that it is what rspec-rails uses. That means it has a certain amount of mindshare. It seems to be the strongest name, but I desire a concensus more than any particular name.

Additionally, rspec-rails is introducing a new type named "features" for tests using Capybara. By separating the ActionDispatch-based tests from the Capybara-based tests it seems to clarify their purpose a bit more IMO. I plan on creating a gem to do something similar with capybara and minitest.

[indirect]

I'm 👍 on "request" as well. Not that my opinion has serious weight. :)

[blowmage]

Ping. Can we get some more discussion on this?

[georgeclaghorn]

I like the name "integration." What is being tested? The integrations between multiple controllers.

[jahio]

I would personally support "request" as well, not that my opinion carries any weight either ;-) I don't really care for "system" as it seems really generalized to me. "resources" sounds feasible, but I feel that the mindshare from "request" that rspec has established trumps that. But that's just my opinion, and I'm not even a contributor - just a user! :)

All that said, I'll be the last person on Earth to complain no matter what it's called!

[tenderlove]

This seems OK to me, but I don't have a very strong opinion. I'd prefer to defer to someone else (maybe @dhh) ?

[jeremy]

Appreciate the pull request, but we're not ready to do any mass-renaming at this point. Our http testing apis need some closer consideration. They're relics of a pre-rack rails, before middleware stacks were involved. It's time to reintegrate the separate APIs and use the integration tests' http-oriented API to test controllers.

[blowmage]

@jeremy Gotcha. Thanks for the update. How can I help?

[jeremy]

@blowmage The main drawback of integration testing setup is that it's slower than functional testing. So one way to help is to massively speed up integration tests. Profile the code and make it at least as fast as an equivalent functional test.

Here's a start, comparing functional & integration tests of a simple action:

Functional:

1.9.3-p327 ~/work/apps/bcx master= cat test/functional/bakeoff_test.rb 
require 'test_helper'

class BakeoffTest < ActionController::TestCase
  tests MonitoringController

  100.times do |i|
    test "bake #{i}" do
      get :index
      assert_response :ok
    end
  end
end

1.9.3-p327 ~/work/apps/bcx master= time ruby -Itest:lib test/functional/bakeoff_test.rb 
Run options: 

# Running tests:

....................................................................................................

Finished tests in 1.897544s, 52.6997 tests/s, 52.6997 assertions/s.

100 tests, 100 assertions, 0 failures, 0 errors, 0 skips

real    0m9.597s
user    0m7.338s
sys 0m1.669s

Integration

1.9.3-p327 ~/work/apps/bcx master= cat test/integration/bakeoff_test.rb 
require 'test_helper'

class BakeoffTest < ActionDispatch::IntegrationTest
  100.times do |i|
    test "bake #{i}" do
      get '/up'
      assert_response :ok
    end
  end
end

1.9.3-p327 ~/work/apps/bcx master= time ruby -Itest:lib test/integration/bakeoff_test.rb 
Run options: 

# Running tests:

....................................................................................................

Finished tests in 3.184533s, 31.4018 tests/s, 31.4018 assertions/s.

100 tests, 100 assertions, 0 failures, 0 errors, 0 skips

real    0m10.898s
user    0m8.685s
sys 0m1.679s

The integration tests are roughly 40% slower. Let's erase that gap!

[pixeltrix]

@blowmage if you're interested here's a couple of profiler charts I did to compare what's going on in an integration vs. functional test of a basic rails g controller pages index with just a simple get and assert_response.

Integration Test

Functional Test