Weave Code
Testbench Laravel Package
tipowerup/testbench
Shared Orchestra Testbench foundation for TastyIgniter v4 extensions. Boots full Laravel + TI context for tests with zero duplication: SQLite in-memory DB, array cache, core system tables/migrations, TI providers, temp paths, and extension scanning disabled for isolation.
Shared testing foundation for TI PowerUp extensions. Provides full Laravel + TastyIgniter context in tests with dual-mode support (host app and standalone CI).
Frequently asked questions about Testbench
- How does TI PowerUp Testbench differ from Orchestra Testbench for standard Laravel packages?
- TI PowerUp Testbench extends Orchestra Testbench to include TastyIgniter v4 context, such as core system tables, service providers, and disabled extension scanning for isolation. It’s tailored for PowerUp extensions, offering dual-mode support (host app or standalone CI) to avoid environment-specific test failures.
- Can I use this package if my Laravel app isn’t using TastyIgniter or PowerUp?
- No, this package is specifically designed for TI PowerUp extensions. It assumes TastyIgniter v4 and PowerUp’s architecture, so it won’t work for generic Laravel packages unless they replicate PowerUp’s service container or module structure.
- What Laravel and PowerUp versions does this package support?
- The package requires PHP ^8.3 and TastyIgniter Core ^v4.0. Check its `composer.json` for exact Laravel version constraints, as PowerUp may enforce specific Laravel compatibility. Always verify alignment with your stack before adoption.
- How do I configure the testbench to skip core migrations for my extension tests?
- Set the `$runCoreMigrations` property to `false` in your extended `TestCase`. This disables TI core table migrations (e.g., `settings`, `extensions`) if your tests don’t require them, speeding up test execution.
- Will this package work in CI environments without local .env variables?
- Yes, the standalone CI mode is designed to work without local `.env` files. However, ensure your tests don’t rely on environment-specific configurations (e.g., database URLs, cached services) that aren’t mocked or provided by the testbench.
- Does the testbench support testing PowerUp CLI commands or scheduled jobs?
- The package focuses on HTTP, database, and service provider testing. For CLI commands or scheduled jobs, you’ll need to manually extend the testbench or use Laravel’s `Artisan::call()` within your tests, as these aren’t natively covered.
- How do I add custom PowerUp providers or middleware to the test context?
- Override the `getExtensionProviders()` method in your `TestCase` to return an array of additional providers or middleware. The testbench will register them alongside TI’s core providers, ensuring they’re available in your tests.
- Are there performance concerns with dual-mode (host/standalone CI) support?
- Dual-mode support introduces minimal overhead, primarily during test initialization. The package optimizes by disabling extension scanning and using in-memory SQLite, but complex extensions with heavy dependencies may experience slower startup times.
- What happens if my extension relies on PowerUp’s dynamic module loading?
- The testbench disables extension scanning by default (`autoloadExtensions(false)`) to ensure isolation. If your tests require dynamic module loading, you’ll need to manually enable it or mock the behavior in your `TestCase` setup.
- How do I handle SQLite-incompatible admin migrations (e.g., orders, menus) in tests?
- Admin migrations are opt-in and disabled by default. To include them, override the `shouldRunAdminMigrations()` method in your `TestCase` and return `true`, but note that some migrations (e.g., those using MySQL-specific features) may fail in SQLite.
Weaver
How can I help you explore Laravel packages today?