[10-10EZ] Fill out fields on 10-10EZ pdf and ensure correct data display

[coope93]

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 work is behind a feature toggle (flipper): NO
• Map most of the form data to the correct format to populate the 10-10EZ pdf file.
• This PR fills out the fields on the pdf currently, but does not handle the dynamic fields that can have more than one entry (dependents, income, and insurance information). That work will be in future PRs.
• 1010 Health Apps

Related issue(s)

• Part I PR to add the KEYS const
• [BE] 10-10EZ - Print/save PDF: Map remaining fields and generate PDF va.gov-team#102888

Testing done

• New code is covered by unit tests
• Describe what the old behavior was prior to the change
• Describe the steps required to verify your changes are working as expected. Exclusively stating 'Specs run' is NOT acceptable as appropriate testing
• If this work is behind a flipper:
  • Tests need to be written for both the flipper on and flipper off scenarios. Docs.
  • What is the testing plan for rolling out the feature?

Screenshots

Note: Optional

Example 10-10EZ that has been filled out

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 (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

[github-actions]

1 Warning

⚠️

This PR changes 250 LoC (not counting whitespace/newlines). In order to ensure each PR receives the proper attention it deserves, we recommend not exceeding 200. Expect some delays getting reviews. File Summary Files lib/pdf_fill/forms/va1010ez.rb (+169/-4) spec/lib/pdf_fill/forms/va1010ez_spec.rb (+73/-4) Note: We exclude files matching the following when considering PR size: *.csv, *.json, *.tsv, *.txt, *.md, Gemfile.lock, app/swagger, modules/mobile/docs, spec/fixtures/, spec/support/vcr_cassettes/, modules/mobile/spec/support/vcr_cassettes/, db/seeds, modules/vaos/app/docs, modules/meb_api/app/docs, modules/appeals_api/app/swagger/, *.bru, *.pdf Big PRs are difficult to review, often become stale, and cause delays.

Generated by 🚫 Danger

[coope93]

We are now testing the simple and kitchen_sink examples

[coope93]

Updated this to compare json so the order doesn't matter but it will still confirm all key/values.

[coope93]

Added some specialized specs for fields with defined options

[coope93]

I anticipate some refactoring around all of these merge_field methods. These are all used to ensure the data format we receive from the schema will render properly in the pdf, since often the values for displaying a radio box, check box, or other field is different based on the pdf field. I have been focusing on getting the spec updated to show the correct mapping of fields, so we should be able to refactor it a bit with lots of confidence that the specs will help us ensure everything is lined up correctly.

[coope93]

These are the values the pdf expects for true/false for this question 🤷

[dellerbie]

Non-blocking comments. If you're cool with making no changes from my comments I can change to approved.

[stevenjcumming]

Consider looking into removing the rubocop in a future PR

[dellerbie]

lgtm