- How does AutoTestify compare to manually writing Laravel model tests?
- AutoTestify eliminates repetitive CRUD and uniqueness test boilerplate, saving hours of development time. It generates comprehensive test files for your Eloquent models with a single Artisan command, ensuring consistent coverage for create, read, update, and delete operations while handling unique field validations automatically. However, it’s designed to complement—not replace—manual tests for complex business logic.
- Can I use AutoTestify in Laravel 11+ without a database connection?
- Yes, AutoTestify gracefully handles environments without a database connection. If migrations or doctrine/dbal aren’t available, it falls back to your model’s `$unique` property for uniqueness tests. All database-dependent checks are skipped automatically, making it ideal for database-free workflows like testing APIs or services in isolation.
- Does AutoTestify work with Pest or only PHPUnit?
- AutoTestify generates PHPUnit-compatible test files by default. While it doesn’t natively support Pest’s fluent assertions (e.g., `expect()`), the generated tests can be easily adapted for Pest by manually converting assertions. For large projects, consider post-processing the files or using a wrapper script to ensure compatibility with your preferred testing framework.
- How does schema detection with doctrine/dbal improve test accuracy?
- When doctrine/dbal is installed, AutoTestify dynamically inspects your database schema to detect unique constraints, ensuring tests reflect your actual production constraints. This eliminates the need to manually define `$unique` properties in every model and reduces errors from outdated or mismatched configurations. Without doctrine/dbal, it relies on your model’s `$unique` array, which may not always match the database schema.
- Will AutoTestify generate tests for soft-deleted models or models with custom traits?
- Yes, AutoTestify supports soft deletes (via `SoftDeletes`) and models with common traits like `HasFactory` out of the box. For custom traits or global scopes, the generated tests may require manual adjustments. The package is designed to handle standard Eloquent features but encourages extending its logic for specialized use cases via service provider bindings or model traits.
- Is it safe to commit the generated test files to version control?
- Committing generated test files is generally safe, but consider the trade-offs. AutoTestify’s tests are deterministic and designed to be regenerated without side effects, so they can be version-controlled like any other code. However, if your team prefers on-the-fly generation, you can exclude them from Git and regenerate them during setup or CI. The package includes no hidden state or runtime dependencies that would cause conflicts.
- How do I customize the generated test structure for my team’s standards?
- AutoTestify is extensible via service provider bindings or model traits. You can override default test templates, assertions, or even add custom test cases by publishing the package’s configuration files and extending its logic. For example, you might enforce specific assertion styles, add pre- or post-test hooks, or include model-specific validation rules that aren’t covered by the default generator.
- What’s the performance impact of generating tests for 100+ models?
- Generating tests for 100+ models is lightweight, as AutoTestify uses reflection and optional schema introspection (only when doctrine/dbal is installed). The runtime cost is minimal, typically under a second per model, depending on your system. For large projects, consider running the generator in CI during development phases or using incremental generation (e.g., only regenerate tests for modified models) to optimize build times.
- Can AutoTestify handle polymorphic relationships or many-to-many associations?
- AutoTestify focuses on core CRUD and uniqueness tests for Eloquent models and doesn’t natively generate specialized tests for polymorphic relationships or many-to-many associations. However, you can extend its functionality by creating custom test templates or using the package’s extensibility features to add support for these cases. For now, these scenarios may require manual test writing or post-generation adjustments.
- How do I handle flaky tests generated by AutoTestify in CI/CD?
- Flaky tests can occur if the generated assertions rely on non-deterministic data (e.g., timestamps or auto-increment IDs). AutoTestify mitigates this by using factory-generated data and transaction rollbacks (via `RefreshDatabase`). To further stabilize tests, review the generated files for edge cases, such as race conditions in uniqueness checks, and consider adding retries or custom assertions for critical paths in your CI pipeline.