Weave Code
Eloquent Model Tester Laravel Package
codenco-dev/eloquent-model-tester
Test Eloquent models in Laravel with codenco-dev/eloquent-model-tester. It verifies database table structures, relationships, fillable and guarded fields, and more using factories and the simple HasModelTester trait, helping you catch model issues early with less boilerplate in your test suite.
Eloquent Model Tester is a Laravel dev package that helps you verify your Eloquent models' table structures, relations, and fillable/guarded attributes through your test suite. It integrates seamlessly with PHPUnit, Laravel factories, and RefreshDatabase, letting you assert that your schema and model configuration match expectations.
- Validates database column structure and types
- Checks fillable and guarded attributes
- Tests model relationships
- Works with factories and
RefreshDatabase - Simple trait-based setup per model test
Frequently asked questions about Eloquent Model Tester
- How do I install codenco-dev/eloquent-model-tester in a Laravel project?
- Install it as a dev dependency with composer require codenco-dev/eloquent-model-tester --dev. Then import the HasModelTester trait in a PHPUnit or Pest test class that also uses RefreshDatabase, and call the fluent modelTestable() or tableTestable() helpers. There is no service provider, no config file, and no publish step, so it stays entirely in the require-dev slice of your composer.json.
- Which Laravel and PHP versions does eloquent-model-tester support?
- The package does not publish a verified PHP, Laravel, and database driver support matrix, and its README links factory documentation at Laravel 6.x, which hints at an older origin. Because it relies on schema introspection and Eloquent relation reflection, both of which have shifted across Laravel majors, pin the version and smoke-test it on your target stack first. Also sanity-check the tag history on Packagist and GitHub, since one release date in the package metadata looks anomalous. On a current Laravel release, budget an hour to prove compatibility before rolling it out team-wide.
- How do I test that an Eloquent model has the correct table columns?
- Use the tableTestable() or modelTestable() fluent helpers to assert that the expected columns exist on a model's table; under the hood the package reads Schema::getColumnListing and turns the result into pass or fail assertions. This is a fast way to catch a migration that adds, renames, or drops a column without a matching model update. Be careful with strict variants that assert an exact column set, because they fail on every additive migration. Most teams get more value asserting the presence of key columns than running exhaustive exact-match checks.
- How do I check $fillable and $guarded fields with HasModelTester?
- The trait exposes assertions for $fillable and $guarded, so you can catch a field that is mass-assignable when it should be guarded, or the reverse. These complement table structure checks nicely, since a column can exist in the database and still be missing from $fillable. The README contains a typo in one strict guarded assertion name, something like assetHasOnlyColumnsInGuarded, so confirm the real method names in the source or via your IDE autocomplete. Prefer presence-style assertions unless your fillable list is deliberately frozen.
- Can I test Eloquent relationships like HasMany, BelongsTo, and MorphMany with this package?
- It covers HasOne, HasMany, BelongsTo, HasManyThrough, ManyToMany, MorphTo, MorphMany, and MorphOne by reflecting on the model method and checking it returns the expected relation type. That catches return type changes after a refactor or a copy-paste mistake on an inverse relation. It does not verify behavior, because no rows are joined to prove the foreign key, pivot table, or morph map is correct. Pair it with at least one assertion that actually loads related records so structural coverage does not masquerade as behavioral coverage.
- Does eloquent-model-tester check soft delete columns and query scopes?
- Yes, the assertion set includes soft-delete column checks, which catch a model that uses SoftDeletes while the migration is missing deleted_at, plus checks that declared query scopes exist on the model. Scopes are validated by presence only, so a scope that exists but filters the wrong rows still passes. Treat these as a safety net for renames and removals, not as behavior tests.
- Do I need model factories and RefreshDatabase to use eloquent-model-tester?
- The package assumes a factory exists for every model under test and that the test database schema is migrated, and it does not create either for you. The usual setup is generating factories with artisan make:model MyModel -mf and putting RefreshDatabase on the base tests/TestCase.php so every model test gets a clean schema. SQLite in-memory works fine for introspection, though keep in mind that some drivers report column details slightly differently.
- Is codenco-dev/eloquent-model-tester safe to install in production?
- It is a dev-time testing utility with no production footprint: no service provider side effects, no config to publish, no request lifecycle hooks, and it belongs in require-dev. That means adopting or ripping it out has essentially zero blast radius on a running application. The real risk is test-suite coupling, because if a Laravel upgrade breaks the package your CI fails until you patch or fork it.
- What are alternatives to eloquent-model-tester for testing Laravel models?
- The built-in Laravel equivalents are Schema::hasColumn or hasColumns for structure, assertInstanceOf on a relation method for relation types, and assertDatabaseHas for data behavior. Static analysis tools such as Larastan catch some model property and relation type errors before tests even run. Many teams write a small shared base test case with a few custom helpers, which gives similar ergonomics with no third-party dependency. Reach for eloquent-model-tester when you want the assertions pre-built and are comfortable owning a fork if needed.
- The package looks unmaintained with Travis and StyleCI badges. Should I fork it or avoid it?
- Signals are mixed: an MIT license plus a changelog and releases exist, but roughly 20 stars, zero dependents, and vestigial Travis and StyleCI badges mean it has essentially no downstream battle-testing. The README also alternates between HasModelTester and HasModelTestor and includes a typo'd assertion name, which is mild documentation drift. Since the package is small and architecturally shallow, the pragmatic move is to vendor or fork the trait into your own test suite so a Laravel upgrade cannot break CI. If you keep the Composer dependency, pin it exactly and re-review it on every Laravel major upgrade. Either way, do not treat it as your only model coverage, because it validates structure, not behavior.
Weaver
How can I help you explore Laravel packages today?