Weave Code
Data Provider Laravel Package
ergebnis/data-provider
Generic PHPUnit data providers for booleans, floats, integers, nulls, objects, resources, strings, and UUIDs, so you can reuse consistent test data instead of rewriting provider methods in every test suite.
👓 Provides a composer package with generic data providers for use with phpunit/phpunit.
Frequently asked questions about Data Provider
- How do I install ergebnis/data-provider in a Laravel project?
- Run composer require --dev ergebnis/data-provider from the root of your Laravel application. The package is a plain Composer library with no service provider, configuration file, or published assets, so nothing else needs to be registered. Because it only supplies PHPUnit data providers, it should normally live in require-dev rather than require. After installation, the provider classes are immediately autoloadable from any test class.
- Is ergebnis/data-provider compatible with the PHPUnit version used by Laravel?
- The package targets phpunit/phpunit and follows its modern releases, so it fits the PHPUnit versions shipped with current Laravel skeletons. PHPUnit 10 and later use attributes such as DataProviderExternal, while older Laravel projects on PHPUnit 9 use the equivalent annotation, and the package works with both styles. Always confirm the exact PHP and PHPUnit constraints in the package's composer.json against your application's locked versions before rolling it out. Running your existing test suite once after installation is the quickest compatibility check.
- How do I reference an ergebnis data provider from a Laravel test method?
- Point PHPUnit at the provider's public static method, for example BoolProvider::provideValidBooleans or StringProvider::provideStrings, either with the DataProviderExternal attribute in PHPUnit 10+ or the @dataProviderExternal annotation in PHPUnit 9. The provider returns an array of datasets that PHPUnit passes as arguments to your test method, so your test signature must accept the matching parameters. You can mix these external providers with providers defined inside your own test class. No changes to Laravel's TestCase or test bootstrap are required.
- Which data providers does ergebnis/data-provider include out of the box?
- The package ships BoolProvider, FloatProvider, IntProvider, NullProvider, ObjectProvider, ResourceProvider, StringProvider, and UuidProvider. Each exposes static methods returning datasets for valid values, invalid values, or edge cases depending on the provider. That covers the scalar types most commonly needed when testing casts, validation rules, value objects, and type declarations in a Laravel codebase. ObjectProvider and ResourceProvider are useful when you need non-scalar arguments without hand-rolling fixtures.
- Does ergebnis/data-provider replace Laravel factories, seeders, or Faker?
- No, it complements them rather than replacing them. Factories and Faker create realistic Eloquent models and attribute values tied to your domain, while this package supplies generic scalar and type-level values for data-driven tests. A typical setup uses factories for persisted records and an ergebnis provider for the argument matrix of a single test method. Keeping those responsibilities separate makes tests easier to read and maintain.
- How does ergebnis/data-provider interact with Laravel test helpers like database transactions and RefreshDatabase?
- It does not interact with them at all, because data providers run before the test lifecycle begins to build the dataset list. Laravel's RefreshDatabase, DatabaseTransactions, and factory helpers still execute per test exactly as before. One practical consequence is that you cannot call database-dependent code inside a data provider method, so dataset values should be static or computed without the application container. If you need records, create them inside the test body using factories.
- Can I combine ergebnis data providers with my own custom data provider methods?
- Yes. PHPUnit allows multiple data provider attributes or annotations on a single test, and it also lets you reference external providers alongside methods declared in your own test class. A common pattern is to use StringProvider for generic type coverage and a local provider for domain-specific payloads such as invalid email formats or status transitions. You can also wrap an ergebnis provider inside your own method to add named dataset keys or filter values. This keeps reusable generic data separate from application-specific cases.
- Are named data sets supported so failing tests show readable case names?
- Yes. PHPUnit uses the array keys returned by a provider as dataset names, and you can wrap or map the package's datasets to give each case a descriptive key. Readable names make failure output far clearer, for example showing a null string case instead of a numeric index. If the built-in keys are not descriptive enough for your suite, define a thin custom provider that returns the same values under your own labels. This is purely a readability improvement and does not affect test behaviour.
- Will ergebnis/data-provider slow down a large Laravel test suite or affect production?
- The package has no runtime footprint in production because it is only loaded during test execution. Provider methods are simple PHP functions returning arrays, so the overhead is negligible compared with booting the framework or hitting the database in each test. The only scaling consideration is that very large or heavily nested dataset matrices multiply the number of test cases PHPUnit must run. Keep datasets focused on meaningful edge cases rather than exhaustive permutations.
- Is ergebnis/data-provider actively maintained, and what are the alternatives?
- It is a small, focused package from the ergebnis organisation with CI workflows, code coverage reporting, and a narrow API surface, which keeps maintenance risk low. Community engagement is modest, so issue responses may be slower than with larger libraries, and you should verify release activity on Packagist and GitHub before adopting it. Alternatives include writing custom static provider methods, using Faker for randomised values, or dedicated fixture libraries. Given the small codebase, forking or vendoring a provider is also a realistic fallback.
Weaver
How can I help you explore Laravel packages today?