Asserting API Response
Automation tests are only validating if they assert the expected results. Asserts are used to verify the expected results from the endpoint.
Status Code Asserts:
Status code asserts ensures that the call to the endpoint returns a specific status code when returned.
The most commonly used will be:
->assertOk()
->assertCreated()
->assertNotFound()
->assertNoContent()
->assertStatus()
Laravel Documentation for all available assertions
Example:
An alternative way of testing the status code is by using ->assertStatus(X)
, where X
is the expected status code value e.g. ->assertStatus(200)
.
JSON Response Asserts:
When the request has returned with a response during the functional tests, an assert should be used to determine if the correct response has returned. Add a message to an assert when possible to increase the maintainability of the tests.
Using ->assertExactJson
, the test can compare the response to the exact expected response. The test will fail if there is a difference, and a message within the terminal will print the discrepancy.
Example:
Note that this example is using assertExactJson()
, ensure that the JSON returned by the API matches the array exactly. If a single property is absent, the assertion will fail.
If it is undesirable to assert the entire JSON response, then use ->assertJsonFragment()
Fluent JSON Testing
Laravel offers an alternative way to assert JSON responses using the AssertableJson
utility. For example, when a more complex assertion is needed.
For more info about fluent JSON assertions, check out the official documentation.
AssertableJson asserts
Here are some examples of fluent assertions
When there is a delay between when the request is received and the response is returned by the server, do not use the current timestamp time()
directly in JSON assertions. Instead, save the value of the timestamp in a variable prior to making the request so that it may be asserted against later.
See Laravel API Docs for more advanced fluent methods: Laravel API Documentation
Testing File Uploads
Laravel simplifies testing file uploads using the Illuminate\Http\UploadedFile::fake()
method. For example, when testing a CSV file upload, do the following:
Check the official documentation for information on testing file uploading.
Interacted
Verifying that the test has interacted with all the properties of the JSON response will ensure that updated endpoints not reflected in the test will be caught. The assertion ->interacted()
can be used:
See and Don't See Asserts
These are very easy assertions to see if a specific search string can be found. This can help ensure that deleted entities are not being returned. It is recommended to save data with titles like Deleted_
so that assertions do not misidentify similarly worded entities.
What and what not to assert
When asserting the contents of a JSON response from an HTTP request, only test specific values that are not likely to change.
The ID field from a POST request will likely change as auto-increment values for primary keys may differ.
In GET requests, especially if the seed data specified the same ID for inserting a record, it can be helpful to test if the ID is precisely as expected to ensure the correct records are retrieved.
The created date, updated date, and updated by are likely to change. Avoid checking for exact values.
Use the ->has()
assertion to check if the response contains the correct number of elements.
Incomplete Tests
Mark a test as incomplete for either an unimplemented method or a test that can’t be fully asserted for a specific reason.
markTestIncomplete
should be added to the top of the test method with the context of why the test is incomplete. This prevents the execution of any assertions that follow in the test method.
Last updated