admin/raven-client
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

e2e ftw!

Browse Source
This commit is contained in:
John Cardinal
2021-10-29 00:34:56 +00:00
parent baf0a6bc73
commit 500444b253
3 changed files with 31 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
ayanova/devdocs/todo.txt
View File

@@ -21,22 +21,25 @@ AUTOMATED TESTING
must be runnable here or against devops
Cypress will test e2e
## E2E TESTING
todo:2 cypress testing for load testing etc
has to be done manually, there is a good idea in the comment here:
https://stackoverflow.com/a/51197403/8939
basically, init a new vue ui project, commit it, then add e2e plugin then recommit to see what all changed so can then manually remove that from main project
Look at moving to a standalone Cypress setup, why bother with the one built into vue ui, it doesn't seem to offer any benefits to doing it alone
this way can be fully up to date etc
https://www.cypress.io/
Remove from vue ui project but make copy of tests first
then make new project folder for this and put the tests there
install standalone cypress and go it without vue stuff
todo: soak test over the weekend?
Cypress dashboard free self hosted alternative if I need it: https://docs.sorry-cypress.dev/guide/get-started
todo: discuss with Joyce reporting requirements and if we are at the stage to be making any real world reports yet
todo: create e2e "supersmoke" test that excercises *all* of AyaNova
not enough to just open pages and look for elements, that's not catching if server is involved beyond serving the app pages
Step1 create a unique naming variable prefix for all testing data so can run over and over
Sets itself up with what it needs, assumes as little as possible pre-existing
Must create unique records, maybe including logins
Must create every type of record possible then re-open and verify they exist
Schedule will benefit from having made a findable workorder to then look for in month / day view
Reporting?
At the end of the day it must be a acceptance test we can rely and and also to add bug issues to that are then fixed to detect regressions
todo: load / soak test over the weekend?
todo: discuss reporting requirements and if we are at the stage to be making any real world reports yet
- stripped down bare reports with as little extra elements on page as humanly possible (as per dashboard UI advice guy)
- let the user add any elements if they want them, we want as white a page as possible in our stock reports, clean, simple, no extra bits anywhere
- Reports, where it's at and about muted style for them