Asserts that `page` can be rendered without raising a fatal error.
For page types with multiple routes, you can use `route_path` to specify a partial path to be added to the page's regular `url`.
When `post_data` is provided, the test makes a `POST` request with `post_data` in the request body. Otherwise, a `GET` request is made.
When supplied, `query_data` is always converted to a querystring and added to the request URL.
When `user` is provided, the test is conducted with them as the active user.
By default, the assertion will fail if the request to the page URL results in a 301, 302 or 404 HTTP response. If you are testing a page/route where a 404 response is expected, you can use `accept_404=True` to indicate this, and the assertion will pass when encountering a 404 response. Likewise, if you are testing a page/route where a redirect response is expected, you can use `accept_redirect=True` to indicate this, and the assertion will pass when encountering 301 or 302 response.
This assertion is great for getting coverage on custom rendering logic for page types. Here is an example:
Asserts that the page edit view works for `page` without raising a fatal error.
When `user` is provided, the test is conducted with them as the active user. Otherwise, a superuser is created and used for the test.
After a successful `GET` request, a `POST` request is made with field data in the request body. If `post_data` is provided, that will be used for this purpose. If not, this data will be extracted from the `GET` response HTML.
This assertion is great for getting coverage on custom fields, panel configuration and custom validation logic. Here is an example:
Asserts that the page preview view can be loaded for `page` without raising a fatal error.
For page types that support different preview modes, you can use `mode` to specify the preview mode to be tested.
When `user` is provided, the test is conducted with them as the active user. Otherwise, a superuser is created and used for the test.
To load the preview, the test client needs to make a `POST` request including all required field data in the request body. If `post_data` is provided, that will be used for this purpose. If not, the method will attempt to extract this data from the page edit view.
This assertion is great for getting coverage on custom preview modes, or getting reassurance that custom rendering logic is compatible with Wagtail's preview mode. Here is an example:
Assert a particular child Page type can not be created under a parent Page type. `parent_model` and `child_model` should be the Page classes being tested.
```python
def test_cant_create_under_event_page(self):
# You can not create a ContentPage under an EventPage
Assert that a child of the given Page type can be created under the parent, using the supplied POST data.
`parent` should be a Page instance, and `child_model` should be a Page subclass. `data` should be a dict that will be POSTed at the Wagtail admin Page creation method.
If you want to create page objects within tests, you will need to go through some steps before actually creating the page you want to test.
- Pages can't be created directly with `MyPage.objects.create()` as you would do with a regular Django model, they need to be added as children to a parent page with `parent.add_child(instance=child)`.
- To start the page tree, you need a root page that can be created with `Page.get_first_root_node()`.
- You also need a `Site` set up with the correct `hostname` and a `root_page`.
```python
from wagtail.models import Page, Site
from wagtail.rich_text import RichText
from wagtail.test.utils import WagtailPageTestCase
from home.models import HomePage, MyPage
class MyPageTest(WagtailPageTestCase):
@classmethod
def setUpTestData(cls):
root = Page.get_first_root_node()
Site.objects.create(
hostname="testserver",
root_page=root,
is_default_site=True,
site_name="testserver",
)
home = HomePage(title="Home")
root.add_child(instance=home)
cls.page = MyPage(
title="My Page",
slug="mypage",
)
home.add_child(instance=cls.page)
def test_get(self):
response = self.client.get(self.page.url)
self.assertEqual(response.status_code, 200)
```
### Working with Page content
You will likely want to test the content of your page. If it includes a `StreamField`, you will need to set its content as a list of tuples with the block's name and content. For `RichTextBlock`, the content has to be an instance of `RichText`.
environment, and using Django's [dumpdata](https://docs.djangoproject.com/en/stable/ref/django-admin/#django-admin-dumpdata) command.
Note that by default `dumpdata` will represent `content_type` by the primary key; this may cause consistency issues when adding / removing models, as content types are populated separately from fixtures. To prevent this, use the `--natural-foreign` switch, which represents content types by `["app", "model"]` instead.
### Manual modification
You could modify the dumped fixtures manually, or even write them all by hand.
