-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GPII-3333: Improve production tests to cover more functionality #718
Conversation
Preliminary checkin to keep a copy of the work so far on github. Not ready for use.
Used "hostname" instead of host (and correct path). "Ready" test still fails.
- Use bug fix for cloud based flowmanger /ready endpoint (GPII-3551) - Also, revert docker command to run production tests
CI job passed: https://ci.gpii.net/job/universal-tests/1386/ |
- used user ID veriable and termMap instead of hard-coding ID, - used directModel argument to send() for passing access token.
CI job passed: https://ci.gpii.net/job/universal-tests/1391/ |
CI job passed: https://ci.gpii.net/job/universal-tests/1396/ |
CI job passed: https://ci.gpii.net/job/universal-tests/1406/ |
tests/ProductionConfigTests.js
Outdated
config: { | ||
configName: "gpii.tests.productionConfigTests.config", | ||
configPath: "%gpii-universal/tests/configs" | ||
}, | ||
components: { | ||
healthRequest: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are test definitions that work with development configs, which start both the local flow manager and the cloud locally, for all end points provided by the cloud. It would be beneficial for reducing the work load and future reusability if these test definitions can be reused for the production configs, where the cloud is served by docker containers.
For example, the existing tests for /settings GET is at tests/platform/cloud/SettingsGetTests.js, and for /settings PUT is at tests/platform/cloud/SettingsPutTests.js. The successful and failed cases for /access_tokens can also be found there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cindyli These are the changes thus far for using the test definitions in SettingsGetTests.js
for both development and production configurations. It's still rough, but I'm pushing it to see if it works in CI.
…ction testing Refactoring and defining common test defintions based on existing development settings tests for use with production testing of the cloud based flow manager. Note: too early for use; committing to save the work thus far.
Re-factored and tweaked to have the capability of runnning the "setttings set" tests in either development or production mode.
Updated the developement tests for "put settings" to work with the changes introduced for running "get settings" tests in both development and production configuration.
Renamed to keep the test definitions separate for the "set settings" tests vs. the "put settings" tests.
Previous refactoring of test definitions and code for use in a production configuration requires local declaration of a development configuration for developement tests.
CI job passed: https://ci.gpii.net/job/universal-tests/1429/ |
@@ -12,9 +12,9 @@ | |||
|
|||
"use strict"; | |||
|
|||
var fluid = require("infusion"), | |||
var fluid = require("infusion"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clownspacing has arisen
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I protest my innocence, as I didn't directly touch this file. The extra space is due to merging with @the-t-in-rtf 's GPII-3619 branch before it went into master. See:
gpii = fluid.registerNamespace("gpii"); |
Perhaps the definition of "Clownspacing" is the act of copying other author's mistakes before they make a final cleanup for merging into master. I can live with that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please still remove these extra spaces at line 15 and 17. Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Used npm to run the production configuration tests with separate invocations of npm to add and remove the test gpii keys and prefsssafes.
CI job passed: https://ci.gpii.net/job/universal-tests/1658/ |
CI job failed: https://ci.gpii.net/job/universal-tests/1659/ |
Fixed missed file name.
CI job passed: https://ci.gpii.net/job/universal-tests/1660/ |
CI job passed: https://ci.gpii.net/job/universal-tests/1669/ |
@cindyli ready for review -- thanks. |
gpii.tests.cloud.oauth2.settingsPut.updateSnapset.testLifecycleResponse = function (data, request) { | ||
gpii.tests.cloud.oauth2.settingsPut.updateSnapset.testStatusCode(data, request); | ||
|
||
var lifeCycle = JSON.parse(data); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you normalise capitalisation of "lifeCycle" to "lifecycle" throughout, consistent with usage in the core. Note that this function itself already uses "Lifecycle" in its name. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay
CI job passed: https://ci.gpii.net/job/universal-tests/1677/ |
CI job passed: https://ci.gpii.net/job/universal-tests/1678/ |
}); | ||
|
||
// Tests for deleting test 'user' preferences from the database | ||
gpii.tests.productionConfigTesting.deleteTestRecordsFromDatabaseTests = [{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I should have thought about this much earlier rather than discovering it now. Long story in short, only deleting these records is not enough.
If you look into the CouchDB after running "npm run test:vagarantProduction", there are still some new records in there:
Open one of them, it looks like below and all these new records are in this structure:
These are access tokens assigned to OAuth clients. Refer to the documentation about OAuth authentication GPII supports. Every GET or PUT requests to /settings endpoint requires a valid access token first. This is when they are created. They need to be removed from the database too when the production test completes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Followup, based on a teleconference with @cindyli
- Add a new view to
_design/views
that will find these access tokens based on:
--gpiiKey
--clientCredentials
--type
(always "gpiiAppInstallationAuthorization
")
(Note: The gpiiKey
and clientCredentials
are the same as those used in the test scenario that created the access_token
in the first place.)
Also, this new view will be of use for GPII-3646 where we free up the database of all the expired access tokens created from day-to-day use of the system.
CI job passed: https://ci.gpii.net/job/universal-tests/1684/ |
The technique to remove the extra access tokens is okay, but could be improved. It uses the GPII Key IDs used in the tests to find a subset of access tokens in the database and remove that group. One ID, however, is used elsewhere, namely "carla"; so this will remove all of carla's access tokens, even ones created outside of these tests. An improvement is to use the timestamps within the access tokens, relying on the fact that the "test" access tokens were all created within the last hour (practically speaking, within the last five minutes, or less). Ideally, the code should remove all-and-only the access tokens that were created by the tests. But, because the database cleanup code is run in a separate |
A followup to my comments above. I wrote:
Note that the set-up code in Why not use the flowmanager's |
CI job passed: https://ci.gpii.net/job/universal-tests/1698/ |
Improved technique to remove only the access tokens create by the tests.
CI job passed: https://ci.gpii.net/job/universal-tests/1705/ |
The latest technique is an improvement over the previous one.. It stores the access tokens that the tests create when making flowmanager A few access tokens are still missed, however:
|
- modified vagrantCloudBasedContainers.sh to use the flowmanager's "/ready" endpoint to check its readiness rather than using its "/access_token" endpoint -- avoids creation of extra access token, - modified the deletion of extra gpii keys and pref safes to also remove the access tokens for the login tests for "testUser1" and "nonexistent_gpii_key".
CI job passed: https://ci.gpii.net/job/universal-tests/1723/ |
These modifications take care of the three remaining extra access tokens created by the tests. Ready for reivew, @cindyli |
Merged at 78a7e7a |
JIRA: https://issues.gpii.net/browse/GPII-3333
Adds tests for cloud based flowmanager end points:
Note: Includes changes for GPII-3551 (PR #713)