ap-4463: poc refactor provider_dwp_override flow

[kmahern]

What

Link to story

For review/discussion.

Checklist

Before you ask people to review this PR:

• Tests and rubocop should be passing: bundle exec rake
• Github should not be reporting conflicts; you should have recently run git rebase main.
• There should be no unnecessary whitespace changes. These make diffs harder to read and conflicts more likely.
• The PR description should say what you changed and why, with a link to the JIRA story.
• You should have looked at the diff against main and ensured that nothing unexpected is included in your changes.
• You should have checked that the commit messages say why the change was made.

[naseberry]

♻️ Looks good

The helper seems straightforward, so does the flow update and spec pattern 👍

Depending on how complex or how many more params are required by other flows, would it be ideal to use named params in structs

[jsugarman]

Could use a generic custom matcher since we are going to do a lot of these

quick example:

# spec/support/have_flow_step_args.rb

RSpec::Matchers.define :have_flow_step_args do |expected|
  results = { path: nil, forward: nil, check_answers: nil }

  match do |actual|
    results[:path] = actual.path.call(legal_aid_application) == expected[:path]
    results[:forward] = actual.forward == expected[:forward]
    results[:check_answers] = actual.check_answers == expected[:check_answers]

    results.values.all?(true)
  end

  failure_message do |actual|
    message = ""
    message += "expected #{actual.path.call(legal_aid_application)} to equal #{expected[:path]}\n" if actual.path.call(legal_aid_application) != expected[:path]
    message += "expected #{actual.forward} to equal #{expected[:forward]}\n" if actual.forward != expected[:forward]
    message += "expected #{actual.check_answers} to equal #{expected[:check_answers]}\n" if actual.check_answers != expected[:check_answers]
    message
  end

  description do
    "have matching flow step arguments"
  end
end

And use:

  it "has expected flow step" do
    expect(described_class).to have_flow_step_args(path: "/providers/applications/#{legal_aid_application.id}/check_client_details?locale=en",
                                                   forward: :reeived_benefit_confirmations,
                                                   check_answers: nil)
  end

[kmahern]

I have added a commit to add a custom_matcher similar to the above. To make it generic, I have had to use a common name for the second paramater that is sometimes passed to the step lambda in the specs - I have called it args, but am not sure whether this is confusing?

[jsugarman]

Looks good.

Additional considerations (see comments for examples and details):

1. do we want to namespace further into "collections" of steps?
2. do we want to use keyword args for increased clarity?
3. do we want to use a custom matcher for testing flow steps?

Otherwise 🎖️

[jsugarman]

isn't _options the expected?

[kmahern]

👍

[jsugarman]

This can probably be neatened up by constructing the message as part of the test above and then just results.join("\n") in this block - see be_soap_envelope_with for example.

[kmahern]

👍 have made this change

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication