DEV.co
Open-Source Testing · worksome

request-factories

Request Factories is a Laravel testing utility that eliminates boilerplate when writing HTTP request tests by auto-populating form request fields with sensible defaults. Developers specify test data once in a factory class, then reuse it across tests, focusing assertions on the specific behavior being tested rather than satisfying validation rules.

Source: GitHub — github.com/worksome/request-factories
623
GitHub stars
17
Forks
PHP
Primary language
MIT
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositoryworksome/request-factories
Ownerworksome
Primary languagePHP
LicenseMIT — OSI-approved
Stars623
Forks17
Open issues5
Latest releasev3.5.1 (2026-04-09)
Last updated2026-06-22
Sourcehttps://github.com/worksome/request-factories

What request-factories is

A PHP package (MIT license) extending Laravel's model factory pattern to FormRequest objects. It provides a `RequestFactory` base class with `definition()` and `files()` methods, integrates via macros into FormRequest classes, and supports multiple invocation styles: `factory()->create()`, `fake()`, and Pest's `fakeRequest()` higher-order method. Compatible with PHPUnit and Pest.

Quickstart

Get the request-factories source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/worksome/request-factories.gitcd request-factories# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Reducing test boilerplate in form-heavy Laravel apps

When routes have complex FormRequest validation rules with many required fields, factories let tests specify only fields relevant to the behavior under test, keeping test logic readable and maintainable.

Testing multi-field API endpoints consistently

Teams building REST APIs with numerous endpoints can define factory defaults once per FormRequest, then vary specific fields per test without repeating the entire request payload across dozens of test cases.

Pest PHP test suites with high-order assertions

Projects using Pest benefit from the `fakeRequest()` higher-order method, which chains naturally with Pest's fluent test API and allows inline state overrides while keeping test code compact.

Implementation considerations

  • Factory placement convention: store in `tests/RequestFactories/` with `Factory` suffix matching FormRequest name for automatic Artisan command support.
  • Factory `definition()` method should include all required FormRequest fields with valid defaults; `files()` method handles UploadedFile instances separately.
  • Data precedence is strict: request() payload > state() > definition() > files(). Plan field overrides carefully to avoid subtle test failures.
  • Extend existing factories via inheritance or use `state()` method to create variants; avoid duplicating definition logic across factory subclasses.
  • For tests without a corresponding FormRequest (raw requests), factories still work but require manual class instantiation and do not gain macros on Request class.

When to avoid it — and what to weigh

  • Non-Laravel PHP projects or other frameworks — This package is tightly coupled to Laravel's testing infrastructure, FormRequest class, and Artisan command structure. It does not work outside Laravel.
  • Testing logic outside HTTP request scope — If your tests focus on business logic, domain models, or services independent of HTTP layers, request factories add no value and introduce an unnecessary abstraction layer.
  • Minimal validation rule complexity — For endpoints with only one or two required fields, defining a factory may add more overhead than simply passing field values directly in each test.
  • Projects requiring strict audit trails of all test data — Faker-generated default data and factory state chains can obscure the exact payload being tested; projects with rigorous compliance requirements may need explicit, inline test data instead.

License & commercial use

MIT License. Permissive OSI-approved license permitting commercial use, modification, and distribution with minimal restrictions (retain license notice and liability disclaimer).

MIT License explicitly permits commercial use in closed-source applications and commercial products. No licensing fees, no proprietary restrictions. Include original license text in source distribution if applicable.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationAdequate
License clarityClear
Deployment complexityLow
DEV.co fitGood
Assessment confidenceHigh
Security considerations

No explicit security vulnerabilities mentioned or disclosed in available data. Standard Laravel testing best practices apply: do not use real credentials or production data in factories; use Faker for synthetic data. Since this runs only in test environment (`--dev` dependency), production exposure is minimal. Review generated UploadedFile mocks to ensure they do not cause unintended file operations during tests.

Alternatives to consider

Manual inline test data

Simplest approach for small projects or endpoints with few fields; avoids factory abstraction but requires repeating payloads per test and is harder to maintain at scale.

Laravel Model Factories + seeding

Addresses database state but does not reduce HTTP request payload boilerplate; often used alongside request factories, not as a replacement.

API testing tools (Postman, Insomnia) with collections

External UI-based alternatives for manual API testing; do not integrate into automated test suites and add operational overhead versus in-code factories.

Software development agency

Build on request-factories with DEV.co software developers

Use request factories to eliminate repetitive FormRequest validation payloads. See how Worksome's testing utility can accelerate your test suite.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

request-factories FAQ

Does Request Factories work with PHPUnit, or only Pest?
Works with both. Pest receives additional benefits (higher-order `fakeRequest()` method), but core `factory()`, `fake()`, and `create()` methods are available in PHPUnit tests as well.
Can I use request factories without a FormRequest?
Yes. Factories work with standard Request objects, but you lose the automatic macro registration on the Request class. You must instantiate the factory manually (e.g., `SignupRequestFactory::new()->fake()`).
What if a test needs different data than the factory default?
Data passed directly to `$this->put(..., ['field' => 'value'])` takes highest precedence and overrides factory defaults. Alternatively, chain `state(['field' => 'value'])` before `fake()` to override at factory level.
Is there built-in support for validating factory definitions match FormRequest rules?
Unknown. No mention in README of automatic validation schema matching or IDE support. Define factories manually and test thoroughly to ensure generated data satisfies all FormRequest rules.

Work with a software development agency

From first prototype to production, DEV.co delivers software development services around tools like request-factories. Our software development agency staffs experienced software developers and web developers for custom software development, web development, integrations, and ongoing support across open-source testing and beyond.

Streamline Your Laravel Tests

Use request factories to eliminate repetitive FormRequest validation payloads. See how Worksome's testing utility can accelerate your test suite.