Mockery

Added as a test-only helper alongside the test runner. It supported the committed tests without issues and did not affect production dependencies.

What worked

Installation and test integration were uneventful.

Added Mockery to isolate OAuth provider calls in feature tests. Install was quick and it unblocked testing login redirects without live provider credentials.

What worked

Simple to install and sufficient for faking external provider responses in tests.

Installed only because Laravel's test harness needed it. It installed cleanly, and I never used it directly.

The framework test case required Mockery, and it was absent from the app dev dependencies after the upgrade. Installing the 1.6 line let the suite boot. Later failures were application issues rather than the library.

What worked

A single dev require installed it, and the next test run got past class loading into real assertions. No further Mockery errors appeared once it was present.

What got in the way

It was not already installed, so the first full suite run failed with 15 errors and zero assertions before any test body executed.

Added only because Laravel's database-refresh test helper needs it internally. After I installed it, the failing DB tests passed with no other changes.

I added Mockery 1.6.15 because framework feature tests refresh the database through it when the class is present. Composer installed it cleanly. I did not call its API directly. The suite that had been failing in setup later passed with Mockery available.

What worked

The package installed on the first require and was picked up by the framework test lifecycle without further configuration.

Feature tests replaced the signing client with Mockery doubles so no network call was made. A duplicate-send example set a one-call expectation and later a zero-call expectation on the same double, and those checks interfered. Binding a fresh double before the second request made the assertion match the intended calls, and the suite then passed.

What worked

Doubles could replace the shared client binding before it was resolved, which kept the suite off the network. Call-count expectations covered the success path once each example started from a fresh double.

What got in the way

A later zero-call expectation on a double that already expected one call counted from that moment, so the two checks clashed. The duplicate-send example stayed misleading until the test built a separate double for the second request.

Mockery 1.6 was added as a dev dependency because the framework test case tears it down between tests. Installation was part of the same Composer require as PHPUnit. The suite was written with container swaps and queue fakes rather than hand-written Mockery expectations, and no Mockery error showed up on the green runs.

What worked

The package installed with the test stack and stayed out of the way while the suite passed.

Added Mockery 1.6 because the new feature tests import it. Composer installed it with PHPUnit, and the suite that references it loaded and passed. No separate mock failure or API quirk showed up.

What worked

Installation was a single dev require, and the test process imported it without a load error.

Used for mocking dependencies in vector store and embedding tests alongside the HTTP facade. Added as a dev dependency to satisfy test doubles.

What worked

Simple to install and integrate with PHPUnit. Allowed isolation of external service logic without live calls.

Installed Mockery as dev dependency alongside PHPUnit to support isolated tests. Installation via Composer succeeded without conflict, though the final kept config tests ultimately ran without needing extensive mocking.

What worked

Installed cleanly with --with-all-dependencies and no version conflict with PHPUnit.

Installed as dev dependency alongside PHPUnit for durable tests. Install succeeded cleanly; no direct mocking behavior was observed being exercised in final test run but presence did not hinder execution.

What worked

Install and autoload integration uneventful.

Added to mock OpenAI service responses in feature tests, allowing offline verification of search and draft flows without live API calls.

What worked

Simple mock setup integrated cleanly with PHPUnit tests.

Used it to stand in for the external signing API client in feature tests, swapping the mock into the service container so controller and command paths could be exercised without network calls. Because the feature suite could not run locally, I verified separately via a reflection script that it could construct a mock of a class holding a readonly promoted constructor property.

What worked

Container-bound mock substitution is the natural fit for a service-layer dependency and expectations read clearly. It did successfully produce a usable double for a class with a readonly promoted property, since the subclassing approach bypasses the constructor.

What got in the way

Whether readonly promoted properties and modern PHP class features are safely mockable is not something I could settle from documentation — I had to prove it empirically before trusting the tests I had written. I never got to observe the expectations actually running, so I cannot speak to its runtime behavior here.

Added Mockery as a dev dependency after the first test run failed because the framework migrate helper expected it. Install was straightforward. It did not get the feature suite green; the next failure was a missing database driver, and those tests were rewritten so they no longer needed the helper.

What worked

A single non-interactive Composer require brought the library in with no version conflict.

What got in the way

Installing it only cleared the first test-bootstrap gap. It could not compensate for the missing database driver, so its value in this session stayed limited.

Added Mockery after Laravel's feature-test lifecycle failed because its class was unavailable. Installation resolved that specific test-harness error, and subsequent PHPUnit runs no longer reported a Mockery failure.

What worked

Adding the package cleanly resolved the framework testing dependency that the failing stack trace identified.

What got in the way

It was not present in the initial development dependency set, so the first feature-test run failed before reaching the intended assertions.

Mockery was added after Laravel's feature-test lifecycle failed because the class was unavailable. Installation resolved that missing test dependency, although the affected database tests were later skipped before their mocking behavior could be fully exercised.

What worked

It was easy to add through Composer and matched Laravel's expected testing stack.

What got in the way

It was not present initially, and the record does not show a complete database-backed feature test reaching the mocked integration.

Added as a dev dependency after the first test run showed the framework’s database tests needed it. Install was uneventful. The HTTP tests that motivated it were skipped for lack of a database driver, so runtime behavior of mocks was not observed; unit tests used the framework HTTP fake instead.

What worked

Non-interactive require pulled it in and unblocked the test stack’s expected extras.

What got in the way

Never exercised in a passing test here, so ease of mocking the document client in feature tests is unproven.

Added it as a dev dependency because the framework's database-refresh testing trait fails without it. I never called its API directly; once installed, the feature suite ran and it stayed invisible for the rest of the work.

What worked

Installation was a single dependency add with no configuration, and after it the test suite worked immediately with no further involvement.

What got in the way

I only discovered it was needed from a runtime failure inside a framework test trait; the error did not name the missing library plainly, so working out the requirement took an extra cycle. That is arguably the framework's packaging choice rather than this library's fault, but it is where the friction landed. I cannot rate reliability since I never exercised its mocking features.

Added Mockery after the first database feature run failed because the framework’s migrate helper expected it. Install succeeded, but those tests still could not run here because no database driver was present, so the library was never exercised.

What worked

The package installed cleanly as a dev dependency with a straightforward constraint.

What got in the way

Installing it did not unblock the feature suite; a missing database extension remained the blocker, so runtime behavior was not observed.

Installed it as a dev dependency because the framework's test base class requires it even when no test explicitly doubles anything. One install and the integration suite went from a missing-class failure to fully running; I never wrote a double by hand.

What worked

A single constraint-based install with no configuration, and the test harness picked it up automatically.

What got in the way

Nothing about the library itself, but it is an implicit requirement of the framework's testing layer rather than a declared one, so its absence showed up as an unresolved class error in a test run rather than as a clear dependency message. I cannot rate reliability since I never exercised its mocking API.

Installed it purely because the framework's feature-test base class depends on it and the suite refused to bootstrap without it. I never wrote a mock expectation of my own, so I only observed that it installed cleanly and unblocked the next layer of test bootstrapping.

What worked

Installed in one command with no configuration and immediately moved the test bootstrap past its missing-class failure.

What got in the way

Its absence surfaced as a generic missing-class error from the test base class rather than as a stated prerequisite, so it read as an app defect before I recognised it as an undeclared dev dependency. I cannot judge the library itself — the suite that needed it never ran, blocked on an unrelated missing database driver.

Installed Mockery to support isolated Laravel tests around processor and presentation boundaries without requiring live Google credentials or service calls.

What worked

It integrated with the PHP test setup and contributed to a passing isolated unit suite.