While preparing some contributions I found the RSpec setup can only run unit specs today — the Rails dummy app is scaffolded but was never functional, so controller / request / view / system specs aren't possible. That's also why example_application_tests.rb is empty.
Evidence
-
spec/dummy/Gemfile references a gem that doesn't exist:
gem "feedback_gem", path: "../.."
The gemspec declares spec.name = 'lsa_tdx_feedback'. There is no feedback_gem — looks like a leftover from a rename. bundle install inside spec/dummy fails, so the dummy app has never been booted.
-
spec/rails_helper.rb is empty (0 bytes) — nothing loads the dummy app for specs. .rspec only requires spec_helper, and all current specs are pure unit specs.
-
example_application_tests.rb is empty (0 bytes) — consistent with the above.
-
No system-test stack — no capybara / cuprite / selenium in any Gemfile or the gemspec, so JS behavior (the modal's show/hide, Turbo re-init) can't be covered even once the dummy boots.
Impact
Bug fixes and behavior changes in the view (_feedback_modal.html.erb), the JS (lsa_tdx_feedback.js), and the controller (FeedbackController) currently ship without automated coverage. For example, the current_user NameError (#5) would have been caught by a single controller spec against a dummy app whose ApplicationController doesn't define current_user.
Offer
Happy to wire this up as its own PR if it'd be welcome — roughly:
- fix the
spec/dummy/Gemfile gem name (feedback_gem → lsa_tdx_feedback) and regenerate its lockfile,
- write
spec/rails_helper.rb (boot the dummy, configure rspec-rails),
- add
capybara + a headless driver for the JS/system specs,
- a small CI step to run them.
Because that means choosing a Rails version to test against (the dummy currently pins ~> 6.1), a browser driver, and a CI change, I wanted to raise it as an issue first rather than push an opinionated infrastructure PR. If you'd like it and have preferences on those choices, say the word and I'll follow them.
In the meantime, contributions I send will note where behavior is verified in a consuming app rather than in-gem.
While preparing some contributions I found the RSpec setup can only run unit specs today — the Rails dummy app is scaffolded but was never functional, so controller / request / view / system specs aren't possible. That's also why
example_application_tests.rbis empty.Evidence
spec/dummy/Gemfilereferences a gem that doesn't exist:The gemspec declares
spec.name = 'lsa_tdx_feedback'. There is nofeedback_gem— looks like a leftover from a rename.bundle installinsidespec/dummyfails, so the dummy app has never been booted.spec/rails_helper.rbis empty (0 bytes) — nothing loads the dummy app for specs..rspeconly requiresspec_helper, and all current specs are pure unit specs.example_application_tests.rbis empty (0 bytes) — consistent with the above.No system-test stack — no
capybara/cuprite/seleniumin any Gemfile or the gemspec, so JS behavior (the modal's show/hide, Turbo re-init) can't be covered even once the dummy boots.Impact
Bug fixes and behavior changes in the view (
_feedback_modal.html.erb), the JS (lsa_tdx_feedback.js), and the controller (FeedbackController) currently ship without automated coverage. For example, thecurrent_userNameError(#5) would have been caught by a single controller spec against a dummy app whoseApplicationControllerdoesn't definecurrent_user.Offer
Happy to wire this up as its own PR if it'd be welcome — roughly:
spec/dummy/Gemfilegem name (feedback_gem→lsa_tdx_feedback) and regenerate its lockfile,spec/rails_helper.rb(boot the dummy, configurerspec-rails),capybara+ a headless driver for the JS/system specs,Because that means choosing a Rails version to test against (the dummy currently pins
~> 6.1), a browser driver, and a CI change, I wanted to raise it as an issue first rather than push an opinionated infrastructure PR. If you'd like it and have preferences on those choices, say the word and I'll follow them.In the meantime, contributions I send will note where behavior is verified in a consuming app rather than in-gem.