You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been trying to set up automated testing for Wagtail using the bakerydemo. Since it's also used as the default development project by Wagtail contributors, I think it would make sense for it to be the go-to project for automated and manual testing.
Overall, the bakerydemo does much more than the previous wagtaildemo so it's already a great leap forward. Nonetheless, there are many things that are hard to test at the moment, of which I made a list below. There is one general theme: more features should be used in the demo "out of the box", so that there is the least setup / content loading required when we need to test a given feature.
Here is the list:
Wagtail styleguide – should be enabled in the INSTALLED_APPS.
[ ] Making sessions last a very long time (infinite!).
Have different accounts with different roles, in different groups.
[ ] Have an account with Gravatar.
Have promoted search results.
Have redirects.
Have documents.
Have content/media in collections.
Have focal area used on some images.
Enable the image link generator (I couldn't find it, might have missed it)
Have revisions for some pages
Have pages in draft, live + draft status.
Add rich text using all available formats: bold, italic, p, h2, h3, h4, UL, OL, hr, embed, docs, image, link
Before we go creating fixtures, I think it would be good to discuss which of those things would also be useful for people experimenting with Wagtail, and which are clearly catering for testing only and should be "hidden" one way or another from the normal bakerydemo experience.
The text was updated successfully, but these errors were encountered:
We had quite a few conversations along these lines when first setting up the demo. The general consensus was that we should try and keep things as simple as possible for first time users, whilst giving enough complexity for people new to Wagtail and/or Django to starting getting a sense of how things work. I've no data to back it up with but personally seeing people engage with the demo for the first time I feel like we've got that balance of complexity right.
That said, it definitely could work better as a developer resource. Could one solution be to point to a specific branch for developer installs - much as we currently have where vagrant-wagtail-develop is currently pointing to the Wagtail 2.0 branch?
Agree on all counts with what we need in here. The only one I think I disagree with is:
Making sessions last a very long time (infinite!).
Given how critical login is to the general health of the CMS I think it's important that we be forced through it regularly.
I've been trying to set up automated testing for Wagtail using the bakerydemo. Since it's also used as the default development project by Wagtail contributors, I think it would make sense for it to be the go-to project for automated and manual testing.
Overall, the bakerydemo does much more than the previous wagtaildemo so it's already a great leap forward. Nonetheless, there are many things that are hard to test at the moment, of which I made a list below. There is one general theme: more features should be used in the demo "out of the box", so that there is the least setup / content loading required when we need to test a given feature.
Here is the list:
INSTALLED_APPS
.[ ] Making sessions last a very long time (infinite!).[ ] Have an account with Gravatar.Before we go creating fixtures, I think it would be good to discuss which of those things would also be useful for people experimenting with Wagtail, and which are clearly catering for testing only and should be "hidden" one way or another from the normal bakerydemo experience.
The text was updated successfully, but these errors were encountered: