03 08 2023 Meeting - vanderbilt-redcap/redcap_cypress GitHub Wiki
Meeting Minutes
Updates to RCTF v11.1.5 status
- We are back to 100% pass rate on RCTF steps on v11.1.5 - https://cloud.cypress.io/projects/pvu79o/runs/776/specs
- This includes 435 steps at the moment.
- Tests ran in a total of 2 minutes and 50 seconds.
- Now I can more easily merge across features that are waiting to be reviewed.
CSRF strategy
- No longer any need to deal with CSRF on your own step definitions - https://github.com/aldefouw/redcap_cypress/blob/v11.1.5/cypress/support/commands.js#L1160-L1196
- What are doing now is overriding the click() method.
- If the element we are clicking is an Anchor Tag, Button, or Input Button (without onclick attribute) ... AND the element is part of a form, then we are going to run through some code to ensure that the CSRF token is ready to go before trying to actually click on that element.
- This essentially amounts to waiting until the hidden input field is populated with the CSRF token that REDCap is automatically generating.
- The code to ensure the CSRF token is here - https://github.com/aldefouw/redcap_cypress/blob/v11.1.5/cypress/support/commands.js#L1127-L1158
Element Detachment
- https://github.com/aldefouw/redcap_cypress/blob/v11.1.5/cypress/support/commands.js#L1186-L1189
- I wrote some code to prevent element detachment generically ... I'll have to think about whether we want to keep it. In general, if an element is detaching, we're doing something wrong. We're either not properly monitoring and waiting on an XHR request or we are not waiting for some on screen element to change.
Workflow Notes
- Writing Tests to Prevent Detachment
- I probably have skipped over some testing 101, so here's a crash course on how to write tests ...
Software Testing 101
- PATTERN - The overall pattern we should be following is this:
- action
- assertion
- action
- assertion
- DETACHMENT - Detachment basically is something that happens when we try doing this kind of thing:
- action
- action
- action
- Actions should have consequences so we should not expect the screen would look the same.
IMPORTANT NOTE: I'm also not implying that my tests or step definitions are perfect in sticking to this pattern, this is just a remind to everyone as they work through writing the Gherkin AND step definitions that if we aren't following that pattern, we can get sucked into detachment situations pretty easily.
Tagging
How is tagging going on your current feature commits? Preferred commit style with tags. Example: aldefouw#75. (aldefouw#Issue ID)
Brittle Step Removal
Began removing some of the step definitions that were brittle. Removed PID dependencies on the current features.
Next Steps
I am going to continue with my review of features in the "In Review" column. That means the next feature I'll look over is the "Add / Manage Users" feature. And then "Data Entry through Data Collection Instrument" and so on.
As a reminder, if you have any steps that are selecting elements by ID, like this: https://github.com/aldefouw/redcap_cypress/blob/c513864ebc603259107761d9546d27dfffb45003/cypress/features/core/pre-requisite/assign_super_users.feature#L113-L114
- Those need to be converted to an existing step definition or a special step definition for that specific feature needs to be created.
- In this case, what these steps were doing was checking a box to assign Administrator Privileges to an admin in the system. So what I did was create a step definition that allowed me to either enable or disable the checkbox for those:
- Something I want you to note is that the reason this step definition is robust is because it follows the prescriptive pattern that I showed you:
- action - click on the checkbox to enable or disable the privilege https://github.com/aldefouw/redcap_cypress/blob/v11.1.5/cypress/support/step_definitions/control_center.js#L57
- assertion - make sure that the POST request has happened before allowing the next step to happen https://github.com/aldefouw/redcap_cypress/blob/v11.1.5/cypress/support/step_definitions/control_center.js#L58
NON-TECHNICAL REVIEWER?
I am a TECHNICAL REVIEWER. I do my best to look at the v11.1.5 Test Script and make sure it is adhering to the test script, but because I am constantly dealing with step definitions and framework level stuff, I only have time to scan the Test Scripts.
It would be nice if someone could review the feature tests for readability and correctness against the actual manual Test Scripts. My concern isn't about whether the GIVEN, WHEN, THEN, etc statements are making sense. My concern is whether the steps are passing. There also could be gaps in terms of what we're asserting.
So, for example, is someone willing to read through the "Completed" features and check that the scenarios and steps have the proper keywords AND they read well? I wanted to eliminate all of the esoteric selector statements as well. There's a lot going on and I'm human so I have this feeling I might have missed something.
Meeting Frequency
WORKING MEETINGS
I said that I would put some weekly 9am CST working meetings starting the week of March 15. That is now in place.
Status Updates
- No significant updates. We'll know more after the working meetings next week.