Laravel Boost 2.6: Better Testing Guidance for AI Coding Agents

01

A passing test suite can still miss the point

Imagine an established Laravel portal used to review customer applications. A new feature lets an authorised reviewer approve a case once the required evidence is present. The approval updates the case status, records the decision and dispatches a notification.

The obvious request to an AI coding agent is short: build the feature and add the tests.

Without enough project context, the agent may create a full request test for every missing field, mock the notification system in several places and add model tests that merely confirm an Eloquent relationship returns an Eloquent object. It might also overlook the important boundary: a user without the reviewer role must never approve the case.

None of those weak tests is absurd in isolation. The problem is that an agent sees a local coding task while the team needs a coherent testing strategy. Useful coverage depends on where a rule belongs, what failure would matter and which existing tests already protect the same behaviour.

This is the gap Laravel Boost 2.6 is trying to narrow.

02

What changed in Laravel Boost 2.6

Boost previously distributed testing advice across pest-testing, enforce-testing and phpunit-guidelines. The Laravel team described the overlap as inconsistent, with agents sometimes testing tiny changes, adding unnecessary mocks or writing tests for framework and configuration behaviour.

Version 2.6 consolidates that material into one testing-best-practices skill. Boost composes the installed skill according to the testing packages it finds in the project, including Pest, PHPUnit, browser testing and Test Impact Analysis support where relevant.

That composition matters. A Pest application should not receive a generic essay about every PHP testing tool. The agent needs focused instructions that match the repository it is actually changing.

The important thread is judgement. The skill is not merely teaching an agent how to type a Pest expectation. It is asking the agent to decide what level should own the assertion and what evidence would make the change safe.

03

Skills give the agent detail when the task needs it

Laravel Boost uses guidelines and skills for different kinds of context.

Guidelines are loaded upfront. They give the agent broad conventions about Laravel and the installed ecosystem. Skills are more focused modules that can be activated when the agent is doing a particular kind of work, such as building an Inertia Vue page or writing tests.

That separation helps control context. Loading every testing rule into every conversation would use attention even when the task only changes a translation string. Loading the testing skill when the agent is about to change a business workflow gives those rules a clearer chance to shape the result.

It also means the local repository still matters. Boost can supply Laravel testing practice, but the application should supply its domain language, existing conventions and risk boundaries. A case approval feature may need project-specific instructions explaining the roles, audit record and notification behaviour that must remain intact.

Framework knowledge and application knowledge solve different parts of the problem.

04

How the approval feature should be tested

Return to the case approval workflow. A useful agent should begin by searching the current suite for case permissions, status transitions, audit records and notifications. That discovery reveals whether the project uses Pest or PHPUnit, how users and cases are created and where similar authorisation checks already live.

• A focused test proves the approval service or action changes an eligible case and records the decision.
• A policy or feature test proves an unauthorised user cannot approve the case.
• An endpoint test proves the route connects a valid request to the approval behaviour and returns the expected response.
• A notification test proves the intended message is dispatched once, without testing Laravel's notification framework.

The agent can then propose a small set of tests with distinct jobs.

Validation details should sit at the smallest sensible level. If a dedicated request or rule owns the evidence requirements, test the important input matrix there and keep one representative endpoint case to prove the wiring. Running twenty full HTTP requests to re-prove the same rule adds time without adding twenty times the confidence.

The same restraint applies to mocks. Fake an external boundary or a delivery mechanism when isolation helps. Do not mock the application so thoroughly that the test only proves the mock returns what it was told to return.

This is a better division of labour for AI-assisted development. The agent can search, draft and run the tests quickly. The developer decides whether the proposed boundaries match the business consequence.

05

Updating Boost is part of receiving the new skill

Laravel documents php artisan boost:update as the command for refreshing the local guidelines and skills generated for a project. Teams can also place that command in Composer's post-update-cmd scripts so Boost resources follow dependency updates.

Automation is useful, but generated instruction changes deserve the same calm review as other development tooling.

After updating, inspect the installed skill and ask the agent to explain which existing tests it found before it writes anything. That small question reveals whether the agent is using the repository as evidence or simply producing a familiar testing template.

For the approval feature, I would ask for the proposed test plan before the implementation. The plan should name the business rules, the test level for each one and any coverage already present. If every check has become a browser test, or every class has gained a unit test regardless of behaviour, the plan needs another pass.

06

Database queries now rely on the database to stay read-only

Boost exposes a DatabaseQuery MCP tool so an AI agent can inspect application data while investigating a task. Earlier versions used query parsing and keyword checks to block obvious writes. That is useful, but SQL has more shapes than a list of forbidden words can safely describe.

Boost 2.6 runs those queries inside a database-enforced read-only transaction. MySQL and MariaDB receive a read-only transaction setting, PostgreSQL switches the transaction to read only, and SQLite uses PRAGMA query_only = ON. Boost rolls the transaction back when the query finishes.

This is a sensible defence in depth improvement. The database engine now rejects a modification even if an unusual query shape passes the earlier parsing check.

It is not permission to point an agent at any production database. Use a restricted database account, minimise the data exposed, protect personal information and prefer a safe development or staging data set. A read-only connection can still reveal information that the agent did not need for the task.

Read-only protects integrity. Access control and data minimisation protect confidentiality.

07

The smaller fixes are worth having

The release repairs several less visible problems around agent skills and MCP configuration.

The boost:add-skill command now ignores a repository-root SKILL.md so installation cannot mistake the root file for a skill directory and remove more than intended. It also accepts a wider range of skill path shapes. Schema inspection works with MySQL running in ANSI_QUOTES mode, MCP configuration writing better preserves trailing comments, and agent detection avoids a false Antigravity match caused by Boost's shared .agents directory.

These changes are not headline material on their own, but they matter to trust. AI tooling earns a place in an established application by being predictable around the repository, configuration and data. A clever answer is less useful if installing its context damages the context directory.

08

What the new skill cannot decide for you

The testing skill can improve defaults. It cannot know the commercial cost of an incorrect approval, the regulator's expectations, the team's appetite for browser coverage or the undocumented reason a peculiar regression test exists.

• Does the test protect a behaviour the business relies on?
• Is that behaviour asserted at the smallest useful level?
• Is any important authorisation, hostile input or failure path missing?
• Would the test fail for the defect it claims to prevent?

It also cannot guarantee that a green test proves the right behaviour. An assertion may be clear and still assert the wrong outcome. A test can be isolated and still omit a dangerous permission boundary. A fast suite can still give false confidence if the important integration is mocked everywhere.

That final question catches a surprising amount. Temporarily reverse the condition, remove the permission check or stop dispatching the notification. If the intended test remains green, it is decoration rather than protection.

09

Better guidance should produce a smaller, clearer suite

Laravel Boost 2.6 is useful because it addresses a real weakness in AI-assisted development: agents can create plenty of technically valid work without understanding which work is valuable.

One consistent testing skill gives Laravel agents a stronger philosophy. Find what already exists. Protect the important behaviour. Put each assertion at the right level. Keep setup focused. Test hostile boundaries. Remove duplication rather than congratulating the repository for having a high file count.

The database change follows the same principle. Do not rely only on the agent following an instruction. Put a harder safety boundary underneath it.

For the case approval workflow, success is not a giant collection of generated tests. It is a short suite that proves the authorised path, rejects the unauthorised path, records the decision and sends the right notification. The code should be easier to change because the team knows exactly what the tests protect.

That is the standard I would use when introducing Laravel Boost into an established application: let the agent do more of the searching and drafting, then keep a developer responsible for the boundaries, evidence and final decision.

If you are using AI coding agents on an established Laravel application, I can help set up project-aware guidance, review the test strategy and make sure faster development does not quietly weaken the controls the business relies on.