CODEWITHSUNDEEP
ruby-on-railsrspecsimplecov
Chad
Chad

Reputation: 768

Simplecov wants me to test controller assignments, is there a way to do this without the rails-controller-testing gem?

For a very basic controller action such as:

def new
  @user = User.new
end

Simplecov wants this assignment tested. I can't think of anyway to test it other than using the rails-controller-testing gem which seems iffy since this seems pretty useless to test and not worth installing a gem.

I suspect the correct answer here is to just ignore simplecov, but for the sake of argument if I really want to get 100% coverage, is there any way to actually test this with stock rspec?

Upvotes: 0

Views: 51

Answers (3)

Chad
Chad

Reputation: 768

So to resolve this, it seems like my issue was actually with SimpleCov and Rails 8 beta and simplecov was giving incorrect coverage reports, and it has fixed itself with the final release of rails 8.

Upvotes: 0

wacko
wacko

Reputation: 3424

IMO 100% coverage is a nice to have, but definitively not a must. Adding tests just to reach 100% code coverage is a bad smell. If you feel that the test does not add value, skip it.

Upvotes: 0

max
max

Reputation: 101811

Testing assigment directly is a bad idea.

"Stock RSpec" doesn't actually contain anything Rails specific. That's rspec-rails which is really just a wrapper around Rails own test classes.

Rails has ActionController::TestCase which rspec-rails wraps as controller specs. It is depreachiated and it's use is strongly recommended against outside of legacy applications. What ActionController::TestCase does is create an instance of the controller with a mocked request and then you dispatch the methods directly on the controller instance instead of going through the middleware stack.

What the rails-controller-testing gem does is just restore the depreachiated methods ActionController::TestCase had (assigns) for poking inside the controller instance. It's basically just instance_variable_get and can be easily recreated if you ignore the fact that it's a like a russian doll scheme of bad ideas wrapped in even worse ideas.

If you're actually being a good programmer and using request/system/feature specs the idea of testing instance variables gets even worse.

What they do is send actual HTTP requests to a Rails server running in the background. Meaning that you have to poke into a different process and somehow fish the controller out of the Rack middleware stack and then poke into its instance variables. While this could potentially be done it would be extemely fragile and DHH would forever haunt your dreams.

What then?

Test what the controller does and not how it does it. A simple feature/system spec that creates a user should fail if the instance variable is not assigned.

require "rails_helper"

RSpec.describe "User management", type: :system do
  before do
    driven_by(:rack_test)
  end

  it "enables me to create users" do
    visit "/users/new"
    fill_in "Name", with: "John Doe"
    click_button "Create User"
    expect(page).to have_text "User was successfully created."
  end
end

Upvotes: 0

Related Questions