tapioca icon indicating copy to clipboard operation
tapioca copied to clipboard

Add ActionView::TestCase DSL generator

Open vinistock opened this issue 4 years ago • 1 comments

Closes #570, #494

Motivation

Tests that inherit from ActionView::TestCase have the respective helpers they are testing dynamically included when the test is instantiated.

Basically, this is what Rails does:

# app/helpers/users_helper.rb
module UsersHelper
  def current_user_name
    # ...
  end
end

# test/helpers/users_helper_test.rb
class UsersHelperTest < ActionView::TestCase
  test "current_user_name" do
    # ...
  end
end

# When `UsersHelperTest` is instantiated, Rails dynamically does this
class UsersHelperTest < ActionView::TestCase
  include HelperMethods

  module HelperMethods
    # All available helpers to this test are dynamically included here
    include UsersHelper
  end
end

Implementation

The implementation is straight forward. We gather all tests that inherit from ActionView::TestCase, instantiate the constant with a fake test name to trigger the helpers inclusion and then create the RBI including all of the helper ancestors that were dynamically included.

Concerns

The big challenge for this work is that we currently do not require any test files. In order to actually have this work, we would need to be requiring all test files, which is why I wanted to bring this up for discussion before we move forward.

  • Should we require the test files? We will need a way of preventing the tests from running (i.e.: disable autorun)

Alternative

The alternative implementation would be to not require test files, but to try to figure out the RBIs based on the helpers alone. This also breaks some fundamental assumptions of Tapioca and requires some thought. Namely,

  • We would be using a constant to generate RBIs for a different one (gathering UsersHelper, but generating UsersHelperTest). This requires changes in the DSL generator
  • Another aspect is how to avoid creating unnecessary RBI files. Just because a helper exists, it does mean that its respective ActionView::TestCase test also exists. If we create a test RBI for each helper, we're pretty much guaranteed to generate unnecessary RBIs. We could try to find out whether a test exists, but then that will involve figuring out the right file paths, which is not necessarily enforced (you can put tests for a helper in the wrong path and they'll still run)

Please, let me know your thoughts about the tradeoffs and how you think we should move forward.

Tests

See included tests.

vinistock avatar Nov 16 '21 19:11 vinistock

Blocked waiting for #715.

vinistock avatar Jan 24 '22 20:01 vinistock

Closing this PR for now. It might still be beneficial to create this compiler, but there are other steps that need to be addressed first, like how to load test classes confidently.

vinistock avatar May 06 '24 13:05 vinistock