Skip to content

Add tests for feature-flag route registration across all modules #12

Description

@morcen

Summary

Add real tests for feature-flag-based route registration across all Omni modules so we can verify that each route is registered when its feature is enabled and omitted when its feature is disabled.

Why

The package currently guards route registration in routes/web.php with config checks such as:

  • omni.enabled
  • omni.features.dashboard
  • omni.features.make
  • omni.features.routes
  • omni.features.logs
  • omni.features.queue
  • omni.features.cache
  • omni.features.config

There is already one test in tests/Feature/RoutesPageTest.php named does not register routes when the feature flag is off, but it does not actually assert route registration behavior. It only changes the config value after boot and checks that the config value changed.

That means we still do not have coverage for the behavior that matters most here:

  • whether routes are present when a feature is enabled
  • whether routes are missing when a feature is disabled
  • whether the package-wide omni.enabled switch disables the entire route group
  • whether multi-route features such as make and routes register all expected endpoints together

Because route registration happens at boot time, this is a subtle area that is easy to get wrong and easy to think is tested when it is not.

Current Implementation Notes

Relevant code paths:

  • routes/web.php
  • config/omni.php
  • tests/TestCase.php
  • tests/Feature/RoutesPageTest.php

Current route surface by feature:

  • dashboard
    • GET / named omni.dashboard
  • make
    • GET /make/model named omni.make.model
    • POST /make/model named omni.make.model.generate
  • routes
    • GET /routes named omni.routes.index
    • POST /routes/cache named omni.routes.cache
    • POST /routes/clear named omni.routes.clear
  • logs
    • GET /logs named omni.logs.index
  • queue
    • GET /queue named omni.queue.index
  • cache
    • GET /cache named omni.cache.index
  • config
    • GET /config named omni.config.index

Proposed Scope

Add tests that verify boot-time route registration behavior for all feature flags.

Package-wide toggle

  • when omni.enabled is true, the Omni route group is registered
  • when omni.enabled is false, no Omni routes are registered

Per-feature route registration

For each feature, verify that routes exist when enabled and do not exist when disabled:

  • dashboard
  • make
  • routes
  • logs
  • queue
  • cache
  • config

Multi-endpoint feature coverage

For features that register more than one route, verify the full set:

  • make should register both page and generate endpoints
  • routes should register the index, cache, and clear endpoints

Regression coverage for route names

  • assert the expected named routes are resolvable when enabled
  • assert they are not resolvable when disabled

Suggested Approach

  • add a dedicated feature test file, for example tests/Feature/FeatureFlagRouteRegistrationTest.php
  • configure feature flags before the application boots so route loading reflects the test scenario
  • use fresh application boots or route reloading per scenario instead of mutating config after routes are already registered
  • assert against named routes and/or the router's route collection rather than only asserting config values
  • replace or remove the current placeholder test in tests/Feature/RoutesPageTest.php once the new coverage exists

Acceptance Criteria

  • there is explicit test coverage for omni.enabled
  • each omni.features.* module has a real route registration test
  • make and routes verify all of their endpoints, not just one
  • tests prove registration behavior at boot time, not just config mutation
  • the current placeholder test is replaced with assertions that would fail if route registration regressed

Nice To Have

  • use a data provider or Pest dataset to keep the per-feature assertions concise
  • add a small helper for booting the app with different Omni config combinations to make future route registration tests easier to add

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions