- How do I install laravel-minio-testing-tools in a Laravel project?
- Install it as a dev dependency with composer require --dev protonemedia/laravel-minio-testing-tools, then add the package trait to your base TestCase and publish or adjust its config file. Integration effort is low: roughly half a day to get a first green test against MinIO. Version 1.7.0 introduced no API or config schema changes, so upgrading from a previous release is just a version bump.
- Which Laravel and PHP versions does laravel-minio-testing-tools support?
- The package's own CI now exercises PHP 8.5, which widens the compatibility matrix, but the Laravel-major coverage is not clearly confirmed by the release notes. Verify the supported Laravel versions against your pinned framework version before adopting it. Treat the package's CI configuration as the source of truth rather than the README alone.
- Does laravel-minio-testing-tools require Docker, and can I reuse an existing MinIO service container?
- The package bootstraps a MinIO instance, points a Laravel filesystem disk at it, and tears it down, so it needs a reachable MinIO endpoint during the test run. The provisioning model, whether that is a Docker socket, a testcontainers-style helper, or an assumption that MinIO is already running, is not clearly documented and should be verified in the source. If you already run MinIO as a CI service container, check whether you can override the endpoint so you can drop the Docker dependency entirely.
- How is this different from Laravel's Storage::fake()?
- Storage::fake() swaps in a local driver and never exercises actual S3 protocol behavior such as multipart uploads, presigned URLs, HeadObject, ETag and part semantics, or the difference between 404 and 403 error shapes. This package closes that gap by running your tests against a real S3-compatible server for a fraction of the cost of hitting AWS. It is a convenience wrapper rather than a new capability: you could reproduce it with a CI service container plus roughly twenty lines of config.
- Can I run the MinIO tests in parallel with Pest or ParaTest?
- Parallel execution is the concrete technical risk with this package: port allocation, container reuse, and bucket-name collisions between workers are all unresolved concerns. Nothing in the 1.7.0 release addresses them, and parallel support is not documented. If you rely on parallel test runs, plan to allocate per-worker ports and bucket names yourself, or run the MinIO-backed tests in a separate serial suite.
- Does it work in GitHub Actions and GitLab CI with Docker-in-Docker?
- Your CI environment needs a usable Docker daemon or a reachable MinIO endpoint, so Docker-in-Docker versus socket mounting, privileged mode requirements, and registry pull rate limits all matter. These assumptions are not spelled out in the package documentation and need to be validated on your own pipelines before you commit to it. If privileged mode is not available in your runners, confirm whether pointing the package at a pre-existing MinIO service works instead.
- Does MinIO behave exactly like AWS S3 in tests?
- S3 parity is partial. ACLs, Object Lock, versioning, SSE-KMS, checksum algorithms, and some presigned-URL behaviors differ between MinIO and real AWS S3. Green tests against MinIO are therefore not proof of correctness against S3, they just catch the protocol-level mistakes that Storage::fake() misses. Keep a small smoke suite against real S3 for anything that depends on those features.
- Which MinIO image tag does it use, and can I pin my own version?
- The 1.7.0 release notes do not disclose a change to the default image tag, so verify what the package actually pulls and pin your own tag regardless. MinIO has moved to AGPLv3 and has been stripping console and feature surface from recent image tags, so both the license and the pinned version need legal and security sign-off in CI. Overriding the image tag is the safest way to keep test runs reproducible.
- What are the alternatives to laravel-minio-testing-tools?
- The main alternative is a CI service container running MinIO plus about twenty lines of filesystem disk configuration and teardown code, which is exactly what this package wraps. Laravel's built-in Storage::fake() remains the right choice when you do not need real S3 protocol behavior such as multipart uploads or presigned URLs. A thin testcontainers helper of your own is another option if you need full control over port allocation and parallel runs.
- Is laravel-minio-testing-tools actively maintained and safe to adopt?
- The package is a dev-only dependency with a small vendor, roughly fifteen stars and zero dependents, so community validation is thin and there is no public evidence of large-scale production use. Version 1.7.0 is three Dependabot bumps plus one PHP 8.5 pull request from a first-time contributor, which shows the repo is alive but says nothing about issue response times or bug fixes. Re-check the star count and dependent count before your adoption gate, and treat the automated dependency updates as hygiene rather than a support guarantee.