LG-10670: use different locations for troubleshooting links.

[dawei-nava]

🎫 Ticket

LG-10670

🛠 Summary of changes

When clicking troubleshooting links on the document step, warning screen, review issues screen will generate analytics events with following properties:
name: 'External Direct'
properties.event_properties.step='document_capture'

And different properties.event_properties.location properties:
document_capture, post_submission_warning, post_submission_review

📜 Testing Plan

Provide a checklist of steps to confirm the changes.

• Step 1: Login and go through doc auth agreement page
• Step 2: Go to doc capture page, open new tab for both links in the troubleshooting section.
• Step 3: Failed doc auth and redirected to warning screen, open new tab for both links in the troubleshooting section.
• Step 4: Try again and directed to review screen, open new tab for both links in the troubleshooting section.
• Step 5: query event log with provided properties as filter and verify events logged with corresponding location.

👀 Screenshots

If relevant, include a screenshot or screen capture of the changes.

Before:

After:

Document capture:

Warning:

Reviewing:

[night-jellyfish]

Suggested change

//

[night-jellyfish]

I do wonder if maybe some of these should be separate it blocks, as they seem pretty long for one test (and comments like this in particular feel like an it block).

But, I am less familiar with React and testing in React so maybe the length is necessary. It might be good to have someone more familiar with React to review the tests.

[dawei-nava]

I kind of feels having some duplicate testing verification code, unfortunately did not find something like Rspec behaves like reusables.

For it blocks, all this verification is on the screen controlled by 2/3 flags, it just having quite a lot ui elements rendered.

[eileen-nava]

Hi! I'll tag the @18F/identity-frontend group to do a review and get their opinion about the tests.

[eileen-nava]

Update: I can't actually select @18F/identity-frontend as a reviewer. Not sure why. I'll investigate after my meeting.

[aduth]

Couple ideas for shortening / making reusable:

• Where we're not expecting content to exist, one assertion should suffice, rather than checking the heading, prompt, and button? i.e. if they're all statically rendered via InPersonCallToAction , checking one should be enough.
  • It's not really well supported in our toolchain, but this is where something like shallow-rendering and checking for the rendered existence of some child component would be helpful (e.g. Enzyme shallow rendering with Component finder)
• Create functions to either assert, render common elements, or add common test cases
  • Not React-specific, but some generic example patterns to consider following: itAcceptsAValidDate, createElement
• Have a single spec test the exhaustive set of content expected, then each variation only needs to a small part of that, if it's expected that the content would come together
  • e.g. rather than repeat detailed assertions for troubleshooting links, do the detailed assertion once, and then everywhere else can just check for a list?
    • Or put those assertions into a function?

[dawei-nava]

@aduth good suggestion.

[dawei-nava]

@aduth refactored the test with reusable functions.

[night-jellyfish]

I followed the steps and tested the branch locally, and saw the expected change. 🎉

However, as I said in a comment, I do think it might be beneficial to have someone more familiar with React / JS testing to review the new specs before merging.