Testing Setup and Fixtures
Relevant source files
The following files were used as context for generating this wiki page:
The Resend PHP library employs a testing suite powered by Pest PHP and Mockery. This setup ensures technical reliability by validating API request construction, response parsing, and error handling across various service modules.
Testing focuses on three primary areas: architectural integrity, low-level HTTP transport logic, and high-level service method accuracy. The suite relies heavily on mocked HTTP clients to simulate Resend API responses without performing actual network calls.
Sources: composer.json:20-24, phpunit.xml:4-13
Test Infrastructure and Configuration
The project configuration defines how tests are executed and which tools are available for development.
Test Environment
The phpunit.xml file establishes the default test suite by targeting the ./tests directory for files ending in .php. It enforces strict output standards and enables color-coded results. The configuration also specifies the ./src directory as the primary source for code coverage analysis.
Sources: phpunit.xml:1-21
Core Dependencies
Development dependencies include specialized testing tools:
- Pest PHP: The primary testing framework.
- Mockery: Used for creating mock objects, particularly for the HTTP client.
- PHP CS Fixer: Maintains code style consistency.
Sources: composer.json:20-25
Mocking and Service Testing
Service tests use a mockClient() helper function to verify that SDK methods generate the correct HTTP requests and handle the resulting data objects accurately.
The Mocking Flow
Most service tests follow a standard sequence:
- Define the expected HTTP method, URI, and request body.
- Provide a fixture representing the expected API response.
- Execute the service method.
- Assert that the returned object is the correct instance (e.g.,
Automation,Draft,Webhook) and contains the expected identifiers.
The diagram shows how tests verify the interaction between the service layer and the transporter using mock expectations.
Sources: tests/Service/Inboxes/Draft.php:21-48, tests/Transporters/HttpTransporter.php:33-52
Request and Payload Validation
The suite includes dedicated tests for ValueObjects\Transporter\Payload to ensure that data structures are correctly transformed into PSR-7 compliant requests.
HTTP Method and Body Handling
Tests verify that payloads correctly determine the HTTP method and body contents based on the action type. For example, GET and DELETE requests must not contain a body, while POST and PUT requests must include encoded JSON.
Sources: tests/ValueObjects/Transporter/Payload.php:12-68
Multipart and File Uploads
For operations like contact imports, the test suite validates multipart/form-data construction. This includes verifying the presence of boundaries in the Content-Type header and the correct mapping of file resources and scalar fields.
Sources: tests/ValueObjects/Transporter/Payload.php:110-149
Pagination and Parameters
Payload tests check that list operations correctly append query parameters for pagination, including limit, after, and before cursors.
Sources: tests/ValueObjects/Transporter/Payload.php:44-59
Error Handling and Transporter Tests
The HttpTransporter tests validate the library's resilience against various API failure modes and network issues.
Exception Types
The library maps different failure scenarios to specific PHP exceptions:
| Exception Class | Trigger Condition |
|---|---|
UnserializableResponse | Non-JSON content types, empty bodies, or syntax errors in JSON. |
TransporterException | Network-level issues (e.g., connection timeouts, DNS resolution failure). |
ErrorException | API-level errors returned as JSON (e.g., 401 Unauthorized, 422 Validation errors). |
Sources: tests/Transporters/HttpTransporter.php:69-166
Error Detail Parsing
Tests ensure that ErrorException correctly captures metadata from the Resend API response, such as the name (error type) and message (error description).
Sources: tests/Transporters/HttpTransporter.php:125-140
Data Fixtures
Fixtures provide standardized, static data that mimics Resend API responses. These are typically located in the tests/Fixtures directory and return associative arrays.
Automation Fixture Example
The automation() fixture provides a complex structure including steps and connections, allowing tests to verify deep object graphs without needing a live API.
Sources: tests/Fixtures/Automation.php:3-100
Architectural Constraints
The project uses Pest's architecture testing capabilities to enforce high-level code quality rules.
Debugging Prohibitions
A specific architectural test ensures that no debugging statements, such as var_dump, are left in the production source code. This test only executes when using Pest 2.0 or higher.
Sources: tests/Architecture.php:1-9
The testing setup provides a robust framework that validates every layer of the resend-php SDK, from raw HTTP payloads to high-level architectural standards.