add automation of the RGP proband tab #2160
Conversation
is slightly flaky when checking that textarea notes are preserved after revisiting the page
|
dev probably needs a slight tweak in order for the test to pass - doesn't seem to be housekeeping related - the tweak needed is that the RGP dynamic form -> Contact Info -> State is a textfield in dev env but is a dropdown in test env. It also appears to be a textfield in staging. So it just needs consistency across the 3 non-prod envs. I can just change it so that it looks for a textfield instead of a dropdown though. Passes in test env though. |
|
I ran all tests against Dev on CircleCI. It had one test failure which I think it's related to your change. Can you take a look see to it can be fixed? |
|
if it's the failure for finding the proband tab - that one would be because of housekeeping. Once a participant enrolls in RGP, there should be a proband tab created in RGP but sometimes in dev (and recently test - at least on Friday, I think?) it will not appear without running DSM RGP export - I think it'll be fixed once this ticket is done: https://broadworkbench.atlassian.net/browse/PEPPER-692 |
There was a problem hiding this comment.
There is a problem with test which explains why it doesn't run on CircleCI and localhost. Failure root cause is not related to Housekeeping.
The user object inside the saveParticipantGuid(participantGuid) function is not "known" to the test. user objects in the test and that func are two different objects. Let me know if you have any questions about this.
playwright-e2e/utils/date-utils.ts
Outdated
| @@ -48,3 +48,18 @@ export function offsetDaysFromToday(number = 1, opts: { isAdd?: boolean } = {}): | |||
| } | |||
| return today; | |||
| } | |||
|
|
|||
| export const calculateBirthDate = (month: string, day: string, year: string): number => { | |||
There was a problem hiding this comment.
This func is nice!
How about rename to calculateAge? I think date is not accurate description for what the func do.
| await participantListPage.waitForReady(); | ||
| const participantListTable = new ParticipantListTable(page); | ||
| await participantListPage.filterListByParticipantGUID(user.patient.participantGuid); | ||
| await participantListTable.openParticipantPageAt(0); |
There was a problem hiding this comment.
Need a check to assert one row exists after filter search before open participant page.
| } | ||
|
|
||
| public getPrimaryPhoneNumber(): Locator { | ||
| return this.page.locator("//td[contains(text(), 'Phone')]/following-sibling::td//div//input[@data-placeholder='Phone (Primary)']"); |
There was a problem hiding this comment.
Not a fan of long xpath. It is brittle. We can improve it at a later time.
| this._relationToProband = relationToProband; | ||
| } | ||
|
|
||
| public set relationshipID(relationshipID : string) { |
There was a problem hiding this comment.
Why do we need these set functions?
There was a problem hiding this comment.
plan is to use them at around the next PR when adding family members - but since they're not relevant for this PR I think I'll just take them out and add them back in only if they're actually being used - thinking about it more, that'll help with not causing confusion down the line when seeing a method available that's not clearly being used
works well for new pts - is iffy on existing pts since it seems to timeout when checking for a patch request
basically done by adding an additional check to make sure the text is there before proceeding
skipping until housekeeping stuff is fixed so that tests will pass consistently
is slightly flaky when checking that textarea notes are preserved after revisiting the page
is part 3 of breaking down this large PR: #2048