WIP: test: refactored sign_in method in authentication_helper.rb to set set session variables

[YheChen]

Proposed Changes

(Describe your changes here. Also describe the motivation for your changes: what problem do they solve, or how do they improve the application or codebase? If this pull request fixes an open issue, use a keyword to link this pull request to the issue.)

Refactored AuthenticationHelper#sign_in (in spec/support/authentication_helper.rb) to set the relevant session values directly instead of dispatching a real POST /login request to MainController#login.

Motivation: sign_in is a test helper whose responsibility is to simulate an authenticated session so that other controller tests can exercise their own controller's behavior. It is not responsible for verifying that MainController#login works — MainController has its own spec for that. Routing every test login through the real login action conflated those two responsibilities and, as a side effect, made every call to sign_in invoke User.authenticate, which spawns a subprocess to run the configured validate_file script. Because sign_in is called once per get_as / post_as / put_as / patch_as / delete_as, this added per-test overhead to a large portion of the controller suite.

The new sign_in writes the four session keys that MainController#login would have written on a successful local login:

• session[:auth_type] = 'local'
• session[:real_user_name] = user.user_name
• session[:timeout] = Settings.session_timeout.seconds.from_now.to_s
• session[:has_warned] = false

Subsequent requests in the same example still pass SessionHandler#authenticate's before_action checks because logged_in? and session_expired? only read from these session keys.

Also updated main_controller_spec.rb: 7 tests were asserting on the redirect produced by sign_in's internal post :login, which is exactly the conflation this refactor exposes. They now call post :login directly. One test (LTI launch) additionally needed its cookie value memoized via let to avoid a pre-existing locale-asymmetry bug surfaced by the change.

Screenshots of your changes (if applicable)

Associated documentation repository pull request (if applicable)

Type of Change

(Write an X or a brief description next to the type or types that best describe your changes.)

Type	Applies?
🚨 Breaking change (fix or feature that would cause existing functionality to change)
✨ New feature (non-breaking change that adds functionality)
🐛 Bug fix (non-breaking change that fixes an issue)
🎨 User interface change (change to user interface; provide screenshots)
♻️ Refactoring (internal change to codebase, without changing functionality)
🚦 Test update (change that only adds or modifies tests)	X
📦 Dependency update (change that updates a dependency)
🔧 Internal (change that only affects developers or continuous integration)

Checklist

(Complete each of the following items for your pull request. Indicate that you have completed an item by changing the [ ] into a [x] in the raw text, or by clicking on the checkbox in the rendered description on GitHub.)

Before opening your pull request:

• I have performed a self-review of my changes.
  • Check that all changed files included in this pull request are intentional changes.
  • Check that all changes are relevant to the purpose of this pull request, as described above.
• I have added tests for my changes, if applicable.
  • This is required for all bug fixes and new features.
• I have updated the project documentation, if applicable.
  • This is required for new features.
• If this is my first contribution, I have added myself to the list of contributors.

After opening your pull request:

• I have updated the project Changelog (this is required for all changes).
• I have verified that the pre-commit.ci checks have passed.
• I have verified that the CI tests have passed.
• I have reviewed the test coverage changes reported by Coveralls.
• I have requested a review from a project maintainer.

Questions and Comments

(Include any questions or comments you have regarding your changes.)

[coveralls]

Coverage Report for CI Build 26303551501

Coverage remained the same at 90.225%

Details

• Coverage remained the same as the base build.
• Patch coverage: 14 of 14 lines across 2 files are fully covered (100%).
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	49756
Covered Lines:	45862
Line Coverage:	92.17%
Relevant Branches:	2151
Covered Branches:	971
Branch Coverage:	45.14%
Branches in Coverage %:	Yes
Coverage Strength:	121.85 hits per line

---

💛 - Coveralls