This issue covers the current status of the ui/ux/functional e2e tests coverage. Need lots of help here for anyone that's interested! We are using nightwatch to handle e2e testing. All Admin UI e2e tests are under test/e2e/adminUI These are broken into groups and group related tests within those groups. The groups have a sequence number in them to control the order of execution by nightwatch. To run the tests locally use npm run test-e2e. Make sure you have done a successful npm install for the keystone directory first! If you pick a group/test please mention it here to avoid duplication. Ideally we should focus both on positive and negative testing but at this point positive testing is more important to quickly detect regressions!
noedit:truenocreate:truenodelete:truenoedit:true@webteckie Mark me down for some more simple ones i.e. textarea and url for now.
Out of interest, and maybe for future reference, how many checks need to happen on the more complex types? For example, markdown should display with buttons to make text bold and add links etc. Do we check these are there, and working, and then maybe also somehow check the output html is correct, or do we simply just add some text in the field, without many extra checks.
@jstockwin alright will do! You can add as much testing as you need. Currently we've been adding simple testing just to get the basic stuff covered. But we should really try to cover as much of it as possible.
@webteckie #2709 should be okay to merge now. I'll probably do datetime later, so put me down for a few more. Uhh html, markdown and password?
Presumably the verifyInput checks on password will be a bit different, as it shouldn't display the password in plaintext.
When we get on to the ones with uploads, e.g. cloudinary, s3 and local files, how does this work? Is there a way to upload a file, or do we just check the correct fields are there?
Amazing progress here by the way, This is one of the most important issues we have open currently, it'll massively improve our iteration speed.
Thanks for working on this @joerter @webteckie and @jstockwin, I can't wait to close this issue!
@jstockwin you got the next fields assigned to you...thanks for the awesome work! With regards to the upload ones most likely we'll just do the ui tests until we figure a good way to do the ux tests.
For group 005 tests, boolean, email and number all need refactoring to the new pattern of using page objects, so perhaps need unticking or something to indicate this.
@webteckie All field tests have now been re-factored. At the time of writing this, all the check boxes are up to date.
I just tried safe-deleting adminUI.js, but it's still referenced from the relationships tests in group006, and also in the readme.
I can't see any progress being made for embedly, s3file or azureFiles because these all need config options to be set with valid access tokens/keys etc. Maybe they need to be striked out or something?
Will try and get round to geopoint, numberarray, and textarray in the next few days.
Regarding relationship field tests, since there is a group006 for this, should relationship be removed from group005?
@jstockwin freel free to comment out the adminUI.js references in group006 since that group is TODO. Thank you for getting us this far...amazing!
@webteckie Just a quick one - currently the relationship field tests are for many: false relationships. We should perhaps also add many: true ones, unless you think it's best to just leave them for group006.
IMO there is quite a difference in behaviour between the two cases, so we should treat them as two fields. I'm not going to have time to do this any time soon, but thought I should point it out.
@jstockwin if you are talking about testing more options in the field that should happen in the field tests. If we are talking about app scenarios then should probably be in group007. We should probably get rid of group006 and rename group007 to group006.
@webteckie - yeah, so I think I mean we need to add some more relationship stuff in group005. We need a new model to test many: true relationships, since we don't currently do this.
@jstockwin yeah, that's the plan....feel free :-)
btw, you don't really need a new model. You can just keep adding fields with the different options and expand the field PO, if needed.
We also need to extend the html/markdown tests to include e.g. wysiwyg options.