HTTP Tests
To make a request in your tests, you may use the get
, post
, put
, patch
, or delete
methods within your test. These methods do not actually issue a "real" HTTP request to your application. Instead of returning a Masonit class Response
instance, test request methods return a HTTPTestResponse
instance, which provides a variety of helpful assertions that allow you to inspect and assert application's responses.
Getting request and response
The request and responses of a test can be fetch by accessing the request
and response
attributes.
Registering routes
During tests you can register routes used only for testing purposes. For this you can use the addRoutes()
method at beginning of your tests:
Checking if a route exists
To check if a route exists, we can simple use either get
or post
:
Request Headers
You may use the withHeaders()
method to customize the request's headers before it is sent to the application. This method allows you to add any headers you would like to the request by providing them as a dict:
Request Cookies
You may use the withCookies()
method to set cookie values before making a request. This method accepts a dictionary of name / value pairs:
Authentication
If you want to make authenticated requests in your tests, you can use the actingAs()
method that takes a given User
record and authenticate him during the request.
The authentication guard can also be specified to authenticate the user with the given guard:
The user will be persisted only during the lifetime of the test. Each request made during the test will be authenticated with the given user. If you need to logout the user in the test, you can use actingAsGuest()
method:
CSRF Protection
By default, all calls to your routes with the above methods will be without CSRF protection. The testing code will allow you to bypass that protection.
This is very useful since you don't need to worry about setting CSRF tokens on every request but you may want to enable this protection. You can do so by calling the withCsrf()
method on your test.
This will enable it on a specific test but you may want to enable it on all your tests. You can do this by adding the method to your setUp()
method:
Again you can disable this behaviour with withoutCsrf()
method.
Exceptions handling
As you have noticed, Masonite has exception handling which it uses to display useful information during development.
This is an issue during testing because we wan't to be able to see more useful testing related issues. Because of this, testing will disable Masonite's default exceptions handling and you will see more useful exceptions during testing. If you want to use Masonite's built in exceptions handling then you can enable it by running:
You can also disable exceptions handling again by using:
Available Assertions
Masonite provides a variety of assertions methods to inspect and verify request/response logic when testing your application. Those assertions are available on the HTTPTestResponse
returned by get
, post
, put
, patch
, or delete
.
assertContains
Assert that returned response contains the given content
string. Note that the response content will be eventually decoded if required.
assertNotContains
Assert that returned response does not contain the given content
string. Note that the response content will be eventually decoded if required.
assertContainsInOrder
Assert that returned response contains in order the given strings. Note that the response content will be eventually decoded if required.
assertNoContent
Assert that returned response has no content and the given HTTP status code. The default status code that is asserted is 204.
assertIsNamed
Assert that given route has the given name.
assertIsNotNamed
Assert that given route has not the given name.
assertIsStatus
Assert that the response has the given HTTP status code:
assertOk
Assert that the response returns a 200 status code:
assertCreated
Assert that the response returns a 201 status code:
assertSuccessful
Assert that the response has as status code between 200 and 300
assertUnauthorized
Assert that the response has as 401 status code
assertForbidden
Assert that the response has as 403 status code
assertError
Assert that the response has as 500 status code
assertHasHeader
Assert that the response has the given header name and value (if given).
assertHeaderMissing
Assert that the response does not have the given header.
assertLocation
Assert the response has the given URI value in Location
header.
assertRedirect
Assert that the response is a redirection to the given URI (if provided) or to the given route name with the given parameters (if provided).
assertCookie
Assert that the request contains the given cookie name and value (if provided).
assertPlainCookie
Assert that the request contains the given unencrypted cookie name
assertCookieExpired
Assert that the request contains the given cookie name and is expired.
assertCookieMissing
Assert that the request does not contain the given cookie.
assertSessionHas
Assert that the session contains the given key and value (if provided).
assertSessionMissing
Assert that the session does not contain the given key.
assertSessionHasErrors
Assert that the session contains an errors
key or contains the given list of keys in errors
key.
assertSessionHasNoErrors
Assert that the session does not contain an errors
key or that this key is empty.
assertViewIs
Assert that the route returned the given view name.
assertViewHas
Assert that view context contains a given data key and value (if provided).
assertViewHasExact
Assert that view context contains exactly the given data keys. It can be a list of keys or a dictionary (here only keys will be verified).
assertViewMissing
Assert that given data key is not available in the view context.
assertAuthenticated
Assert that a user is authenticated after the current request.
If a user instance is given it will assert that this user is authenticated:
The authentication guard can also be specified to check the authentication state on the given guard.
assertGuest
Assert that a user is not authenticated after the current request.
The authentication guard can also be specified to check the authentication state on the given guard.
assertHasHttpMiddleware
Assert that the request has the given HTTP middleware. An HTTP middleware class should be provided.
assertHasRouteMiddleware
Assert that the request has the given route middleware. The registration key of the middleware should be provided.
assertHasController
Assert that the route used the given controller. A class or a string can be provided. If it's a string it should be formatted as follow ControllerName@method
.
assertRouteHasParameter
Assert that the route used has the given parameter name and value (if provided).
assertJson
Assert that response is JSON and contains the given data dictionary (if provided). The assertion will pass even if it is not an exact match.
assertJsonPath
Assert that response is JSON and contains the given path, with eventually the given value if provided. The path can be a dotted path.
assertJsonExact
Assert that response is JSON and is strictly equal to the given dictionary.
assertJsonCount
Assert that response is JSON and has the given count of keys at root level or at the given key (if provided).
assertJsonMissing
Assert that response is JSON and does not contain given path. The path can be a dotted path.
Dump Data During Tests
Handy dump
and dd
helpers are available on the HTTPTestResponse
returned by get
, post
, put
, patch
, or delete
during a unit test.
dumpRequestHeaders
After getting a test response back from a request you can dump request headers in console by chaining this helper to the response:
dumpResponseHeaders
After getting a test response back from a request you can dump response headers in console:
ddHeaders
After getting a test response back from a request you can dump response and request headers in console and stop the test execution:
Here assertSessionHas
will not be executed as the test will be stopped before.
dumpSession
After getting a test response back from a request you can dump session data in console by chaining this helper to the response:
ddSession
After getting a test response back from a request you can dump session data in console and stop the test execution:
Here assertSessionHas
will not be executed as the test will be stopped before.
Last updated