Getting Started
Masonite testing is very simple. You can test very complex parts of your code with ease by just extending your class with a Masonite unit test class.
Although Masonite uses pytest
to run tests, Masonite's test suite is based on unittest
. So you will use unittest
syntax but run the tests with pytest
. Because of this, all syntax will be in camelCase instead of PEP 8 lower_case_with_underscores. Just know that all TestCase assertions used during testing is in camelCase form to maintain unittest standards.
Testing Environment
When running tests, Masonite will automatically set the environment to testing
. You are free to define other testing environment configuration values as necessary.
You can create a .env.testing
file. Feel free to load any testing environment variables in here. By default they will not be commited. When pytest
runs it will additionally load and override any additional environment variables.
Creating Tests
You can simply create a file starting with test_
and then creating a test class inheriting from masonite TestCase
class.
You can also directly use the command
to create tests/unit/test_some_feature.py
:
That's it! You're ready to start testing. Read on to learn how to build your test cases and run them.
Running Tests
You can run tests by calling
This will automatically discover your tests following pytest automatic tests discovery. You can also run a specific test class
Or a specific test method
Finally you can re-run the last failed tests automatically
Building Tests
Test Life Cycle
When you run a test class each test method of this test class will be ran following a specific life cycle.
Running the above test class will create this output:
Note that tests methods are not always ran in the order specified in the class. Anyway you should not make the assumptions that tests will be run in a given order. You should try to make your tests idempotent.
Chaining Assertions
All methods that begin with assert
can be chained together to run through many assertions. All other method will return some kind of boolean or value which you can use to do your own assertions.
Asserting Exceptions
Sometimes you need to assert that a given piece of code will raise a given exception. To do this you can use the standard assertRaises()
context manager:
Capturing Output
Sometimes you need to test the output of a function that prints to the console. To do this in your tests you can use the captureOutput()
context manager:
Overriding Debug Mode
Sometimes you would need to change the debug mode value during the lifetime of a test. To do this you can use the debugMode()
context manager:
Dumping Data
During tests execution, print()
statements will not be visible. You can use the dump()
test helper to dump data to console during a test:
Note that you can provide a second argument to name the dump in console.
Stopping Test
If you want to programmatically stop the test execution you can use the stop()
helper. You can even provide a reason.
Test are stopped by returning a pytest 2 exit code (user interruption).
Test Helpers
Masonite comes with different helpers that can ease writing tests. Some of them have already been explained in sections above.
withExceptionsHandling
Enable exceptions handling during testing.
withoutExceptionsHandling
Disable exceptions handling during testing.
Note that exception handling is disabled by default during testing.
withCsrf
Enable CSRF protection during testing.
withoutCsrf
Disable CSRF protection during testing.
Note that CSRF protection is disabled by default during testing.
withCookies
Add cookies that will be used in the next request. This method accepts a dictionary of name / value pairs. Cookies dict is reset between each test.
withHeaders
Add headers that will be used in the next request. This method accepts a dictionary of name / value pairs. Headers dict is reset between each test.
fakeTime
Set a given pendulum instance to be returned when a now
(or today
, tomorrow
yesterday
) instance is created. It's really useful during tests to check timestamps logic.
This allow to control which datetime will be returned to be able to always have an expected behaviour in the tests.
When using those helpers you should not forget to reset the default pendulum
behaviour with restoreTime()
helper to avoid breaking other tests. It can be done directly in the test or in a tearDown()
method.
fakeTimeTomorrow
Set the mocked time as tomorrow. (It's a shortcut to avoid doing self.fakeTime(pendulum.tomorrow())
).
fakeTimeYesterday
Set the mocked time as yesterday.
fakeTimeInFuture
Set the mocked time as an offset of a given unit of time in the future. Unit can be specified among pendulum units: seconds
, minutes
, hours
, days
(default), weeks
, months
, years
.
fakeTimeInPast
Set the mocked time as an offset of a given unit of time in the past. Unit can be specified among pendulum units: seconds
, minutes
, hours
, days
(default), weeks
, months
, years
.
restoreTime
Restore the mocked time behaviour to default behaviour of pendulum
. When using fake
time helpers you should not forget to call this helper at the end.
It can be done directly in the test or in a tearDown()
method.
Last updated