VED-1013 Part 3/4 Add support for running new e2e tests in PR environments#1140
Conversation
|
This branch is working on a ticket in the NHS England VED JIRA Project. Here's a handy link to the ticket: VED-1013 |
| ) | ||
| response.raise_for_status() | ||
|
|
||
| self.created_product_name_uuids = product_name_uuid |
There was a problem hiding this comment.
Either change this from list to str, or append instead of overwriting?
There was a problem hiding this comment.
Oh yeah, should be singular. We only need 1 product. Multiple apps. Have resolved now.
| "name": product_name_uuid, | ||
| "apiResources": [], | ||
| "approvalType": "auto", | ||
| "description": "My API product", |
There was a problem hiding this comment.
Description could be something like "Autogenerated API product for E2E tests"
|
| os.environ[f"{test_app.supplier}_client_Id"] = test_app.client_id | ||
| os.environ[f"{test_app.supplier}_client_Secret"] = test_app.client_secret | ||
|
|
||
| yield created_apps |
There was a problem hiding this comment.
This is cool. I had to look up what yield does 😄
There was a problem hiding this comment.
Yup, I've used it before in Python generators but not in test fixtures like this. Generally useful for where you're concerned about memory e.g. holding a full list of objects in memory vs. just yielding the next item is much more efficient. I've only had to worry about that a couple of times in my actual life when it's not been a silly Advent of Code thing.
In the test fixture it's very nice, because all the teardown runs after irrespective of whether the test failed or succeeded.



Summary
Routine Change
Copies and majorly refactors existing e2e code that creates and tears down on demand Apigee products and apps.
Makes the above code accessible in the new e2e_automation directory. The original e2e code that is being replaced will be deleted in the final PR after this.
Adds support so that when we are running tests against a PR proxy then we will generate the apps and overwrite the relevant clientID and client secrets for all our mock test apps.
Documentation
I am very proud of point 4. I started off messing around with lots of bits in the e2e_automation tests and tried to use a single mock app for the "Test_App" supplier, but the approach I've taken I believe is very much lovelier.
Reviews Required
Review Checklist
ℹ️ This section is to be filled in by the reviewer.