Mobile: Create EVSSClaim even when using lighthouse

[Tonksthebear]

Note: Delete the description statements, complete each step. None are optional, but can be justified as to why they cannot be completed as written. Provide known gaps to testing that may raise the risk of merging to production.

Summary

This should reduce/remove claim decision letter 404s when combining lighthouse with EVSS

Related issue(s)

https://app.zenhub.com/workspaces/va-mobile-60f1a34998bc75000f2a489f/issues/gh/department-of-veterans-affairs/va-mobile-app/8324

Testing done

Added test to ensure EVSSClaim are being created even when using lighthouse

Screenshots

Note: Optional

What areas of the site does it impact?

(Describe what parts of the site are impacted andifcode touched other areas)

Acceptance criteria

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected
• I added a screenshot of the developed feature

Requested Feedback

(OPTIONAL)What should the reviewers know in addition to the above. Is there anything specific you wish the reviewer to assist with. Do you have any concerns with this PR, why?

[aherzberg]

LGTM. Looks like even if this got left in and EVSS got turned off, this would still work since it's just a locally stored vets-api table. right?

[Tonksthebear]

LGTM. Looks like even if this got left in and EVSS got turned off, this would still work since it's just a locally stored vets-api table. right?

Ya it's low risk to leave in and the table gets cleared every day so we wouldn't grow a massive database or anything. Still worth removing eventually but not dangerous code

[aherzberg]

LGTM

[kpethtel]

You could definitely improve the tests further by having creating an explicit "creates record when none exists" test (rather than including it in another test) and an "updates record when it does exist".

[kpethtel]

I would write this as:

expect {
  get('/mobile/v0/claims-and-appeals-overview', headers: sis_headers, params:)
}.to change(EVSSClaim, :count).by(1)

[Tonksthebear]

I originally was going to write it that way, but I thought the get being in a block would mess up the response variable. I guess not though, I'm changing it

[Tonksthebear]

You could definitely improve the tests further by having creating an explicit "creates record when none exists" test (rather than including it in another test) and an "updates record when it does exist".

@kpethtel Good point, also that'll make removing the tests that much easier when this becomes unnecessary. Updated 👍

[kpethtel]

Nice work. Thanks for improving the tests.