Unit Bundle Laravel Package

Getting Started

• Install as a dev dependency with Composer, then run the package’s test suite or a single smoke test to confirm the test case base classes and helpers autoload correctly.
• Look first at the package README and src/ for the core entry points: CommandTestCase, AbstractCommand, the fixture creation helpers, ConnectionFactory, and the SQLite language extensions. In v1.0.2 the fixture helpers, buildObject, and ConnectionFactory are the most useful places to start.
• First practical use case: create a command test by extending the package’s command test case, define a small fixture, and assert command output/exit code. This exercises the fixed CommandTestCase helper handling and AbstractCommand error handling in one pass.
• If your app relies on MySQL date formatting in tests, try the new SQLite DATE_FORMAT function early. It lets SQLite-backed tests behave closer to MySQL without switching the test database.
• For fixture-heavy tests, use the new handy fixture-creation functions and buildObject to reduce boilerplate before building out larger test suites.

Implementation Patterns

• Command testing: Extend the provided command test case instead of raw PHPUnit/Laravel test cases when testing Artisan commands. Use the package’s helper methods inside commands and assertions; v1.0.2 specifically fixes helper usage within CommandTestCase.
• Fixture inheritance: Define shared fixture properties on base fixture classes and override only what each test needs. v1.0.2 fixes fixture creation when properties are inherited, so this pattern is now safer for reusable fixture hierarchies.
• Service mocking before fixtures: Register mocked container services before loading fixtures. The release fixes unmocked services during fixture loading, but ordering still matters: mock first, then create fixtures that resolve those services.
• Object construction in tests: Use buildObject across all test types to construct test doubles or domain objects consistently. This is useful when you want the same construction path in unit, feature, and command tests.
• Database isolation: Use the improved ConnectionFactory to standardize test database connections, especially when mixing SQLite in-memory tests with connection-specific setup. Keep connection configuration centralized rather than hand-rolling connections per test.
• SQLite/MySQL parity: Use the new SQLite DATE_FORMAT function in queries exercised by tests when production uses MySQL. This is a test-parity tool, not a replacement for verifying real MySQL behavior in integration environments.
• Container annotations: If your tests rely on container annotation checks, keep annotations explicit and close to the test case or fixture. v1.0.2 fixes bad annotation checking, so previously silent annotation mistakes may now surface as failures.

Gotchas and Tips

• Annotation failures after upgrade: The fixed annotation checking can expose incorrectly written container annotations that previously passed. Run the affected test suite after upgrading and correct annotations rather than weakening the check.
• Mock timing: If a fixture resolves a service from the container, the mock must already be bound. The v1.0.2 fix addresses unmocked services during fixture loading, but tests that bind mocks after fixture creation can still see the real service.
• Inherited fixture properties: Fixture creation for inherited properties is fixed, but be careful with property visibility and defaults. Prefer explicit base fixture properties over magic dynamic properties when debugging fixture state.
• Command helpers: CommandTestCase helper behavior is fixed, but helpers used inside commands may still depend on the command being bootstrapped through the package’s test case. Do not instantiate commands manually if the test relies on helper injection.
• SQLite DATE_FORMAT scope: The new function is added to the SQLite language layer. It will not make SQLite fully MySQL-compatible; use it for date-formatting parity and keep MySQL-specific SQL coverage in a MySQL-backed test job where possible.
• ConnectionFactory configuration: The improved factory is convenient, but keep connection names and driver options explicit in test configuration. Avoid sharing a single connection across tests that mutate schema or transaction state.
• buildObject consistency: Since buildObject is now available for all tests, standardize on it for object creation where possible. Mixing manual new calls with buildObject can hide container or mocking differences between test types.
• Debugging strategy: When a v1.0.2-related failure appears, isolate whether it is fixture creation, service mocking, command bootstrapping, or SQLite function behavior. The release notes map cleanly to those four areas, so bisect along those boundaries first.