@mmcev106
At UW, we have a working prototype of global enable / disable of External Modules at the cypress.env.json level so that we do not have to use "prerequisite" Gherkin steps within a scenario to enable an EM before being able to test it.
It was pushed to this branch: https://github.com/vanderbilt-redcap/rctf/commits/em_global_test/
You can get a pretty good sense of what it's doing looking at this:
https://github.com/vanderbilt-redcap/rctf/pull/86/changes
Here's how it works:
-
External Modules are enabled / disabled based upon their folder name within the /modules/ folder.
-
The module names must be explicitly specified within the bootstrap_settings block of cypress.env.json
"bootstrap_settings": {
"modules": {
"my_em_v1.0.0": true,
"my_other_em_v1.0.0": false
}
}
This approach is straight-forward and deterministic since it will always match the folder name within modules.
-
If you mark an EM as "true", it is globally enabled for feature test runs. If you mark an EM as "false", it is globally disabled for feature test runs.
-
Mechanism: We're using what is hopefully a long-lived XHR route within REDCap to enable the module:
<REDCap Version>/ExternalModules/manager/ajax/enable-module.php
This seemed safer than raw SQL - but maybe it isn't? I'm open to suggestion.
In any case, we pass the EM prefix and version, in addition to a CSRF token. If there is a better way for us to do this, we're open to it.
Results
In our testing, this method is working very well for us. It saves a lot of time and it has been working reliably to explicitly enable / disable modules that are functional.
Shortcomings
This is simple enable / disable functionality. It does not handle any advanced configurations.
It also relies on the Login method being called. The Test_Admin automatically logs in to grab a CSRF token before enabling the modules. I am not sure this is avoidable unless we were to use raw SQL to enable the modules.
Next Steps
Can you please review the code and let us know what you think of this approach? We're happy to go a different direction if preferred, but we had to start somewhere with a prototype and this is working for us so far. Eager to hear your feedback.
@mmcev106
At UW, we have a working prototype of global enable / disable of External Modules at the
cypress.env.jsonlevel so that we do not have to use "prerequisite" Gherkin steps within a scenario to enable an EM before being able to test it.It was pushed to this branch: https://github.com/vanderbilt-redcap/rctf/commits/em_global_test/
You can get a pretty good sense of what it's doing looking at this:
https://github.com/vanderbilt-redcap/rctf/pull/86/changes
Here's how it works:
External Modules are enabled / disabled based upon their folder name within the
/modules/folder.The module names must be explicitly specified within the bootstrap_settings block of
cypress.env.jsonThis approach is straight-forward and deterministic since it will always match the folder name within modules.
If you mark an EM as "true", it is globally enabled for feature test runs. If you mark an EM as "false", it is globally disabled for feature test runs.
Mechanism: We're using what is hopefully a long-lived XHR route within REDCap to enable the module:
<REDCap Version>/ExternalModules/manager/ajax/enable-module.phpThis seemed safer than raw SQL - but maybe it isn't? I'm open to suggestion.
In any case, we pass the EM prefix and version, in addition to a CSRF token. If there is a better way for us to do this, we're open to it.
Results
In our testing, this method is working very well for us. It saves a lot of time and it has been working reliably to explicitly enable / disable modules that are functional.
Shortcomings
This is simple enable / disable functionality. It does not handle any advanced configurations.
It also relies on the Login method being called. The Test_Admin automatically logs in to grab a CSRF token before enabling the modules. I am not sure this is avoidable unless we were to use raw SQL to enable the modules.
Next Steps
Can you please review the code and let us know what you think of this approach? We're happy to go a different direction if preferred, but we had to start somewhere with a prototype and this is working for us so far. Eager to hear your feedback.