71787 CIE VAOS Appointment Serializer

[kanchanasuriya]

Summary

• Serializer implementation for VAOS appointment data

Related issue(s)

• https://app.zenhub.com/workspaces/check-in-experience-61fc23a2cb8a14001132e102/issues/gh/department-of-veterans-affairs/va.gov-team/71787

Testing done

• New code is covered by unit tests

What areas of the site does it impact?

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

Acceptance criteria

• I added unit tests for each feature (if applicable).
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs

[github-actions]

1 Warning

⚠️

This PR changes 268 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 modules/check_in/app/serializers/check_in/vaos/vaos_appointment_data_serializer.rb (+19/-0) modules/check_in/spec/serializers/vaos/vaos_appointment_data_serializer_spec.rb (+249/-0) Note: We exclude files matching the following when considering PR size: *.csv, *.json, *.tsv, *.txt, 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 Big PRs are difficult to review, often become stale, and cause delays.

Generated by 🚫 Danger

[randomsync]

do we really need to put the whole payload here to test the serializer, or can we trim it?

[kanchanasuriya]

Thought of having the real sample data received from VAOS service

[randomsync]

there's almost 300 lines of the payload, that are IMHO unnecessary. I would suggest trimming it and keeping the parts that are really needed to test the serializer and trimming the rest.

[kanchanasuriya]

Trimmed test data further to reduce the line of code in 7188cf.