Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions app/controllers/concerns/idv/verify_info_concern.rb
Original file line number Diff line number Diff line change
Expand Up @@ -185,6 +185,7 @@ def async_state_done(current_async_state)
state: pii[:state],
state_id_jurisdiction: pii[:state_id_jurisdiction],
state_id_number: pii[:state_id_number],
state_id_type: pii[:state_id_type],
extra: {
address_edited: !!idv_session.address_edited,
address_line2_present: !pii[:address2].blank?,
Expand Down Expand Up @@ -273,12 +274,14 @@ def idv_result_to_form_response(
state: nil,
state_id_jurisdiction: nil,
state_id_number: nil,
state_id_type: nil,
extra: {}
)
state_id = result.dig(:context, :stages, :state_id)
if state_id
state_id[:state] = state if state
state_id[:state_id_jurisdiction] = state_id_jurisdiction if state_id_jurisdiction
state_id[:state_id_type] = state_id_type if state_id_type
if state_id_number
state_id[:state_id_number] =
StringRedacter.redact_alphanumeric(state_id_number)
Expand Down
4 changes: 4 additions & 0 deletions spec/controllers/idv/verify_info_controller_spec.rb
Original file line number Diff line number Diff line change
Expand Up @@ -389,6 +389,10 @@
},
),
)

event = @analytics.events['IdV: doc auth verify proofing results'].first
state_id = event.dig(:proofing_results, :context, :stages, :state_id)
expect(state_id).to match(a_hash_including(state_id_type: 'drivers_license'))
Copy link
Copy Markdown
Contributor Author

@n1zyy n1zyy Oct 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't find prior art for handling this situation...

I basically wanted:

  expect(@analytics).to have_logged_event(
    'IdV: doc auth verify proofing results',
    hash_including(
      {
        proofing_results => context => stages => state_id => { state_id_type: 'drivers_license' }
      },
    ),
  )

except that's not valid code. I started nesting hash_including but it got really unwieldy fast.

hash_including doesn't look deep in the hash, e.g., just doing hash_including(state_id_type: 'drivers_license') expects a top-level key named state_id_type; it doesn't dig down recursively until it finds a match.

The test above feels inelegant, except compared to every other option I tried.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we have one double-nested hash-including here:

success: true, errors: hash_including(message: nil), destination: :link_sent, flow_path: 'hybrid', step: 'hybrid_handoff', analytics_id: 'Doc Auth', telephony_response: hash_including(errors: {}, message_id: 'fake-message-id', request_id: 'fake-message-request-id', success: true), selfie_check_required: boolean

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but I think that you're right, doing a point-check is clearer here

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's almost like we need have_logged_event to support a pattern like:

expect(@analytics).to have_logged_event(
    event_name, 
    hash_deeply_including(
        [:proofing_results, :context, :stages, :state_id],
        {state_id_type: 'drivers_license'},
    ),
)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lmgeorge Something like this came up in the #rspec-league channel when I asked about this, even with some example code. I'm reluctant to add it, though. I feel like it would normalize having deeply-nested hashes for important things, but I feel like it's an antipattern.

I think I agree more with the comment in that thread that something being clunky to test is often a smell that the code (or here, data structure) is too convoluted. That's not an easy fix in this PR, though.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. This is one of those do you fix "all the things" or just try to make your current need work. Either way, adding a custom matcher or dramatically restructuring the analytics event is beyond the scope of this PR.

end
end

Expand Down
20 changes: 15 additions & 5 deletions spec/features/idv/analytics_spec.rb
Original file line number Diff line number Diff line change
Expand Up @@ -70,6 +70,10 @@
jurisdiction_in_maintenance_window: false }
end

let(:state_id_resolution_with_id_type) do
state_id_resolution.merge(state_id_type: 'drivers_license')
end

let(:resolution_block) do
{ success: true,
errors: {},
Expand Down Expand Up @@ -121,6 +125,12 @@
}
end

let(:doc_auth_verify_proofing_results) do
base_proofing_results.deep_merge(
context: { stages: { state_id: state_id_resolution_with_id_type } },
)
end

let(:in_person_path_proofing_results) do
{
exception: nil,
Expand All @@ -144,7 +154,7 @@
vendor_name: 'ResolutionMock',
vendor_workflow: nil,
verified_attributes: nil },
state_id: state_id_resolution,
state_id: state_id_resolution_with_id_type,
threatmetrix: threatmetrix_response,
},
},
Expand Down Expand Up @@ -227,7 +237,7 @@
),
'IdV: doc auth verify proofing results' => {
success: true, errors: {}, flow_path: 'standard', address_edited: false, address_line2_present: false, analytics_id: 'Doc Auth', step: 'verify',
proofing_results: base_proofing_results
proofing_results: doc_auth_verify_proofing_results
},
'IdV: phone of record visited' => {

Expand Down Expand Up @@ -347,7 +357,7 @@
),
'IdV: doc auth verify proofing results' => {
success: true, errors: {}, flow_path: 'hybrid', address_edited: false, address_line2_present: false, analytics_id: 'Doc Auth', step: 'verify',
proofing_results: base_proofing_results
proofing_results: doc_auth_verify_proofing_results
},
'IdV: phone of record visited' => {

Expand Down Expand Up @@ -464,7 +474,7 @@
),
'IdV: doc auth verify proofing results' => {
success: true, errors: {}, flow_path: 'standard', address_edited: false, address_line2_present: false, analytics_id: 'Doc Auth', step: 'verify',
proofing_results: base_proofing_results
proofing_results: doc_auth_verify_proofing_results
},
'IdV: phone of record visited' => {
proofing_components: base_proofing_components,
Expand Down Expand Up @@ -701,7 +711,7 @@
),
'IdV: doc auth verify proofing results' => {
success: true, errors: {}, flow_path: 'standard', address_edited: false, address_line2_present: false, analytics_id: 'Doc Auth', step: 'verify',
proofing_results: base_proofing_results
proofing_results: doc_auth_verify_proofing_results
},
'IdV: phone of record visited' => {

Expand Down