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.
The request and responses of a test can be fetch by accessing the request
and response
attributes.
During tests you can register routes used only for testing purposes. For this you can use the addRoutes()
method at beginning of your tests:
To check if a route exists, we can simple use either get
or post
:
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:
You may use the withCookies()
method to set cookie values before making a request. This method accepts a dictionary of name / value pairs:
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:
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.
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:
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
.
Assert that returned response contains the given content
string. Note that the response content will be eventually decoded if required.
Assert that returned response does not contain the given content
string. Note that the response content will be eventually decoded if required.
Assert that returned response contains in order the given strings. Note that the response content will be eventually decoded if required.
Assert that returned response has no content and the given HTTP status code. The default status code that is asserted is 204.
Assert that given route has the given name.
Assert that given route has not the given name.
Assert that the response has the given HTTP status code:
Assert that the response returns a 200 status code:
Assert that the response returns a 201 status code:
Assert that the response has as status code between 200 and 300
Assert that the response has as 401 status code
Assert that the response has as 403 status code
Assert that the response has as 500 status code
Assert that the response has the given header name and value (if given).
Assert that the response does not have the given header.
Assert the response has the given URI value in Location
header.
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).
Assert that the request contains the given cookie name and value (if provided).
Assert that the request contains the given unencrypted cookie name
Assert that the request contains the given cookie name and is expired.
Assert that the request does not contain the given cookie.
Assert that the session contains the given key and value (if provided).
Assert that the session does not contain the given key.
Assert that the session contains an errors
key or contains the given list of keys in errors
key.
Assert that the session does not contain an errors
key or that this key is empty.
Assert that the route returned the given view name.
Assert that view context contains a given data key and value (if provided).
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).
Assert that given data key is not available in the view context.
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.
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.
Assert that the request has the given HTTP middleware. An HTTP middleware class should be provided.
Assert that the request has the given route middleware. The registration key of the middleware should be provided.
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
.
Assert that the route used has the given parameter name and value (if provided).
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.
Assert that response is JSON and contains the given path, with eventually the given value if provided. The path can be a dotted path.
Assert that response is JSON and is strictly equal to the given dictionary.
Assert that response is JSON and has the given count of keys at root level or at the given key (if provided).
Assert that response is JSON and does not contain given path. The path can be a dotted path.
Handy dump
and dd
helpers are available on the HTTPTestResponse
returned by get
, post
, put
, patch
, or delete
during a unit test.
After getting a test response back from a request you can dump request headers in console by chaining this helper to the response:
After getting a test response back from a request you can dump response headers in console:
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.
After getting a test response back from a request you can dump session data in console by chaining this helper to the response:
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.