Download the PHP package tobento/app-testing without Composer

App Testing

Testing support for the app.

Table of Contents

• Getting Started
  • Requirements
• Documentation
  • Getting Started
  • Config Tests
  • Http Tests
    • Request And Response
    • Subsequent Requests
    • File Uploads
    • Crawl Response Content
    • Json Response
    • Response Macros
    • Refresh Session
    • Dump Response
    • Response Emitter
  • Http Client Tests
  • Auth Tests
    • Authenticating Users
    • Adding Permissions
    • Seeding Users
  • File Storage Tests
  • Queue Tests
  • Event Tests
  • Mail Tests
  • Notifier Tests
  • Database Tests
    • Reset Databases
    • Replace Databases
  • Logging Tests
  • Addons
    • Languages Addon
• Credits

  ---

Getting Started

Add the latest version of the app testing project running this command.

Requirements

• PHP 8.4 or greater

Documentation

Getting Started

To test your application extend the class.

Next, use the method to create the app for testing:

Tmp App

You may use the method, to create an app for testing individual boots only.

Finally, write tests using the available fakers.

By default, the app is not booted nor run yet. You will need to do it on each test method. Some faker methods will run the app automatically though such as the fakeHttp method.

Using onCreateApp()

In addition to the createApp() method, you may use onCreateApp() inside your test methods to register custom implementations - such as routes, middleware, or service overrides - needed specifically for that test.

When onCreateApp() is executed, the application has not been booted yet. This allows you to use $app->on() to modify or extend services before they are resolved. The callback you provide will be applied to every app instance created during the test, including those created internally during redirects.

App clearing

When creating a tmp app, you may call the method to delete the app directory.

Or you may use the method:

Config Tests

In some cases you may want to define or replace config values for specific tests:

Http Tests

Request And Response

If you have installed the App Http bundle you may test your application using the method.

Request method

Or you may prefer using methods:

Use the method to create a request with the following headers:

Response method

Calling the response method will automatically run the app.

withoutMiddleware

previousUri

You may set a previous uri if your controller uses the previous uri to redirect back if an error occurs for example.

Http Url

You may sometimes wish to modify the http url in order to have relative urls for instance;

Subsequent Requests

After making a request, subsequent requests will create a new app. Any fakers from the first request will be rebooted.

Following redirects

File Uploads

You can use the file factory to generate dummy files or images for testing purposes:

Create a fake image

Create a fake file

Crawl Response Content

You may crawl the response content using the Symfony Dom Crawler.

assertNodeExists

assertNodeMissing

Example Form Crawling

JSON Response

You may test JSON responses using the method.

Assertable Json

You may use the class to fluently test JSON responses.

Assert Key

Assert that the key exists:

Assert Value

Assert that the value matches:

Assert Key And Value

Assert that the value matches the key value:

Assert Items

Asserts that the items count matches.

Assert Passes

Asserts that passes evaluates to true.

Hasnt

Use the method asserting the opposite of the method.

Response Macros

You may want to write convenience helpers to the test response using macros.

Refresh Session

You may refresh your session after each test by using trait:

Dump Response

You may use the dump methods to examine and debug the PSR-7 response contents:

Response Emitter

When your application emits a PSR-7 response directly-bypassing the normal HTTP kernel-you can fake the response emitter to capture and assert against the emitted response.

This is useful when testing:

• download handlers
• streaming responses
• services that manually emit responses
• middleware or components that call the emitter directly

You may fake the response emitter as follows:

Notes

• The fake emitter automatically re-registers itself when the testing framework boots a new app instance
  (for example during followRedirects()).

• TestResponse is fully supported, including:
  • status assertions
  • header assertions
  • body assertions
  • JSON assertions
  • macro support

For a full list of available TestResponse methods, see the
Request And Response - Response Methods section.

Http Client Tests

If you have installed the App Http bundle, you may test outgoing HTTP requests made by your application using the fakeHttpClient method.

When your application makes outgoing HTTP requests using a PSR-18 client, you can intercept and assert those requests by faking the HTTP client.
This allows you to test integrations such as webhooks, API calls, and external services without performing real network requests.

Fake Response

You may fake the response returned by the next outgoing HTTP request.
This is useful when testing how your application behaves when an external API returns a specific status code, headers, or body.

Fake Exception

You may fake an exception that will be thrown on the next outgoing HTTP request.
This is useful for testing how your application handles network failures, timeouts, or unexpected client errors.

Inspecting Requests

You may inspect the recorded outgoing HTTP requests for debugging or for writing additional custom assertions.
This is useful when you need to check headers, payloads, query parameters, or the order of requests.

Auth Tests

If you have installed the App User bundle you may test your application using the method.

Authenticating Users

The next two examples assumes you have already seeded test users in some way:

Example With Token

You may want to authenticate a user by creating a token manually:

Adding Permissions

If your application uses the ACL system, you may assign permissions to the authenticated user using the addPermissions() method.

Permissions are applied immediately and are also re-applied automatically when the testing framework boots a fresh app instance (for example during followRedirects()).

Seeding Users

This is one possible way of seeding users for testing. You could also seed users by creating and using Seeders.

You may check out the User Seeding to learn more about the .

File Storage Tests

If you have installed the App File Storage bundle you may test your application using the method which allows you to create a fake storage that mimics the behavior of a real storage, but doesn't actually send any files to the cloud. This way, you can test file uploads without worrying about accidentally sending real files to the cloud.

Example using a tmp app:

Storage Method

Storages Method

Queue Tests

If you have installed the App Queue bundle you may test your application using the method which allows you to create a fake queue to prevent jobs from being sent to the actual queue.

Example using a tmp app:

Clear Queue

Sometimes it may be useful to clear the queue using the method:

Run Jobs

Sometimes it may be useful to run jobs using the method:

Event Tests

If you have installed the App Event bundle you may test your application using the method which records all events that are dispatched and provides assertion methods that you can use to check if specific events were dispatched and how many times. Currently, only Default Events will be recorded. Specific Events are not supported yet.

Example using a tmp app:

Mail Tests

If you have installed the App Mail bundle you may test your application using the method which allows you to create a fake mailer to prevent messages from being sent.

Example using a tmp app:

Notifier Tests

If you have installed the App Notifier bundle you may test your application using the method which allows you to create a fake notifier to prevent notification messages from being sent.

Example using a tmp app:

Database Tests

If you have installed the App Database bundle you may interact with your databases.

Reset Databases

There are two strategies to reset your databases:

Refresh Strategy

This strategy cleans your database after each test.

Migrate Strategy

This strategy cleans your database after each test using migrations.

Replace Databases

You may replace your database to test different databases.

Example replacing the default storage database:

Logging Tests

If you have installed the App Logging bundle you may test your application using the method which allows you to create a fake logger to prevent logging with the actual logger.

Example using a tmp app:

Addons

Languages Addon

If you have installed the App Language bundle you may test your application using the trait which allows you to register languages using the method. The first locale is the default language.

Credits

• Tobias Strub
• All Contributors
• Spiral Framework - Testing - For Inspiration and Code Snippets