Data Provider Laravel Package

Getting Started

1. Install via Composer: composer require --dev ergebnis/data-provider.
2. Start by defining a basic provider using DataProvider::fromArray() or fromIterable(), passing a typed array of fixtures (e.g., #[DataProvider\Name('valid user')] ['id' => 1, 'name' => 'Alice']).
3. Annotate a test method with #[DataProvider\Name('valid user')] or use @dataProvider to consume named datasets—ideally by importing providers via use and referencing them directly (e.g., MyTest::dataProvider()).
4. First use case: replace repetitive @dataProvider arrays in multiple tests with a single reusable provider file (e.g., src/Test/DataProvider/UserProvider.php), exporting clean, typed fixtures.

Implementation Patterns

• Decompose complex datasets: Build providers in layers—e.g., a base UserProvider with valid/invalid users, extended by UserWithPermissionsProvider adding role mappings.
• Leverage fromTraversable() for dynamic generation: Use generators or collections (e.g., from factories or DB fixtures) as inputs to avoid loading all data into memory.
• Combine providers: Use DataProvider::merge() or concat() to unify unrelated datasets (e.g., merge UserProvider + ProductProvider for integration tests).
• Integrate with test traits: Create TestCase subclasses or traits that include default providers (e.g., getStandardUserProvider()), promoting consistency across test suites.
• Type-driven development: Enforce structure via PHPDoc or typed arrays (array{foo: int, bar: string}), and use static analysis tools to validate provider data shapes.

Gotchas and Tips

• Provider naming collisions: Ensure unique provider names when merging—duplicate names silently override. Prefer namespaced naming (e.g., UserProvider::VALID_WITH_ADMIN) or namespaces in provider classes.
• Static analysis gotcha: PHPStan/Psalm may not infer provider types if returned from methods; annotate method returns with iterable|array or use @phpstan-return for precision.
• Debugging: When a test fails mid-provider, enable PHPUnit’s --testdox and --verbose to trace which named provider triggered the failure.
• Configuration quirks: The package has no config file—customization happens via typed provider implementations and test method annotations.
• Extension points: Implement custom DataProviderInterface subclasses for advanced behaviors (e.g., random data generation via Faker, context-aware fixtures).
• Testing providers themselves: Write dedicated tests for your providers using DataProvider::toArray() to assert dataset contents—prevents regressions in test fixtures.