JSON to PDF validation for form submission

[baltes]

As a CHAMPVA applicant, I need my form data to populate correctly in the PDFs sent to the back office for processing.

Scope for this story is form 10-10d.

Acceptance criteria

• All PDFs tied to a single form submit are populated correctly
• Automated tests verify that all PDFs are populated correctly
• Errors in PDF generation are reported by automated testing

Reference

See this post/thread in Slack for more info.

Evaluate pdf_filler_spec.rb and pdf_spec.rb for implementing these automated tests.

[balexandr]

@baltes This was approved and merged to master https://github.com/department-of-veterans-affairs/vets-api/pull/17375

[baltes]

@balexandr questions:

• How do we monitor errors?
• Does this check run each time a form is submitted?
• Does it have to be added to each form or is it just added to the form filler?

[balexandr]

@baltes

1. How do we monitor errors?
   • DataDog is for monitoring any type of coding error. FrontEnd is for controlling data integrity before hitting the BackEnd. What other errors are you thinking about?
2. Does this check run each time a form is submitted?
   • This is just a unit test as what Adrian was talking about. It's meant to take a properly filled out PDF and check our code against it whenever it's run. If, for example, a form mapping got accidentally updated, or a key/value was deleted, this test would now fail because the filled out PDF text and the generated PDF text would no longer match.
3. Does it have to be added to each form or is it just added to the form filler?
   • Sorry, I don't understand this question.

[baltes]

@balexandr Do we need an additional ticket to add metrics for this to datadog?

Question two is about when the test is run and how it's visible when it fails. If we implement this on 10-10d and it only breaks when we have more than three applicants and need more than one PDF, what do we have to do to make sure that scenario would be caught? Just trying to fill my own knowledge gaps of the testing pyramid and what other work we might still need to do.

Do we need additional tickets to implement this for each form, or is it implemented in reuasable code that will apply to all of them? (do we need a ticket for 10-10d, a ticket for 10-7959f-1, etc)

[balexandr]

@baltes Which metric specifically? I think we have everything we can have covered on the BE so far.

Our tests have to pass before we merge any code changes to higher environments. So if we update the code, and it breaks this test we'll know immediately. It's set up to fail if there is an overall text mismatch between a filled.pdf and the test's generated one.

We will need future tickets for new forms. In this ticket, I did it for 10-10D, 10-7959C, 10-7959F-1 and 10-7959F-2

[baltes]

Thanks, that helps and I think that last sentence covered what I was trying to ask.