Write automated tests

● Here's a test plan for the hide_submit module.

Test Plan: hide_submit

This is a contributed module (composer-installed), so tests should live in the module's own tests/ directory. The module is small — one service, one
config form, two permissions, one route. No database tables. All testable behavior is in PHP; the JS is out of scope for PHPUnit.

What to test

1. HideSubmitFormAlter service (Kernel test)

This is the core logic. Test the alterForm() method under different conditions:

- Form gets #attached libraries and drupalSettings when a normal user submits
- Users with "bypass hide submit" permission do NOT get form alterations
- User 1 (admin) is NOT bypassed even if they have the permission (line 33 — intentional behavior)
- When method is "indicator", the spin and ladda libraries are attached
- When method is "disable" or "hide", only the base library is attached
- Config values (reset_time, abtext, hide_text, etc.) are correctly passed through to drupalSettings
- Integer casting works for reset_time and spinner_lines

2. HideSubmitSettingsForm (Kernel test)

- Form builds with correct default values from config
- Submitting the form persists all settings to hide_submit.settings config
- validateNumeric rejects non-numeric input (e.g. "abc", "12.5")
- validateNumeric accepts valid integers (e.g. "5000", "12")
- getFormId() returns hide_submit_settings
- getEditableConfigNames() returns ['hide_submit.settings']

3. Configuration (Kernel test)

- Installing the module creates hide_submit.settings with expected defaults
- Default method is "disable", default reset_time is 5000, default spinner_lines is 12, etc.

4. Permissions and routing (Kernel test)

- The two permissions ("administer hide submit", "bypass hide submit") exist after install
- The route hide_submit.settings resolves to the correct controller and requires "administer site configuration"

What NOT to test

- JavaScript behavior (hide_submit.js, spin.min.js, ladda.min.js) — requires browser testing, out of scope
- CSS rendering
- The controller class — it's a one-liner that renders the form, tested indirectly by the form test

Test structure

tests/
src/
Kernel/
HideSubmitFormAlterTest.php — service behavior + permission bypass logic
HideSubmitSettingsFormTest.php — config form build/submit/validate
HideSubmitConfigTest.php — install config defaults

Priority

1. HideSubmitFormAlterTest — highest value. This is the only real logic in the module. The permission bypass and library attachment branching are the most
likely places for regressions.
2. HideSubmitSettingsFormTest — medium value. The numeric validation and config persistence are worth covering.
3. HideSubmitConfigTest — low value but quick to write. Confirms install config is sane.

Notes

- The module has minimal dependencies (just drupal:system), so kernel tests should boot quickly.
- The bypass logic on line 33 ($this->currentUser->id() != 1) is a loose comparison — worth a test to document the intended behavior.