feature: callouts audit [NP-2114]

[luke-hill]

• Adds in 2 new scenarios for rendering rules
• Uses some clever new SitePrism inheritance to check for presence / overloaded classes

Also fixed up some leftover code regarding APP_ENVIRONMENT vs TESTING_BASE_URL

[davidsauntson]

Small change about the nest heading level checks - we aren't really testing anything here since it's hard coded and the code to test is in the public website repo (and is not limited to callouts but handles all heading levels generally).

[davidsauntson]

what does the be_all_there method test?

[luke-hill]

that validates the presence of either
a) All defined SitePrism constructs within your scope
b) All permissible SitePrism constructs within your scope.

[davidsauntson]

OK thanks - so in this case the inner_adviser falls into (b) above because its section definition is nested inside the one for outer_standard?

[luke-hill]

sorry I forgot to explain another tiny little bit, but you're basically correct.

I have got a long-standing piece of work to also allow recursion. So the way you detect if it's a or b is if there is a DSL definition of expected_items that will "filter" and only check for certain things.

outer_standard.all_there? => Checks outer_standard.heading and outer_standard.message
outer_standard.all_there?(recursion: :one) => Checks all of the above, then finds all section and sections definitions. For each of those, perform item.all_there? So in this instance it will check outer_standard.inner_adviser.heading outer_standard.inner_adviser.message and outer_standard.inner_adviser.label

[luke-hill]

See https://github.com/site-prism/site_prism-all_there/blob/main/lib/site_prism/all_there/recursion_checker.rb#L15-L27 for more info.

[davidsauntson]

Cool, thanks for the info!

I wonder if it's easier to just be explicit about what you're expecting and have two be_present calls, one for each callout?

[luke-hill]

I could do that if you'd prefer. In this situation that's not a problem because the items being enumerated are singular. So I can do it in 2.

But if the item being enumerated was plural, it could be say 10 items (Then it would be quite impractical).

Is there something language wise that's tricky to understand with the all_there assertion?

[luke-hill]

To clarify would you prefer either

expect(a).to be_all_there(recursion: :one)

expect(a).to be_all_there

expect(b).to be_all_there

or

expect(a).to have_xxx

expect(a).to have_yyy

expect(b).to have_xxx
... and so on...

Note the latter is going to create a lot of overhead

[davidsauntson]

Thanks for this - no major problem now I know 😄

[davidsauntson]

There is no code in the design system that changes the heading levels - it's all done in the public website here: https://github.com/citizensadvice/public-website/blob/develop/app/lib/formatters/heading_formatter.rb

The tests for this code should be in that repo (there are already spec tests).

This variant is just here for the VRTs and docs.

[luke-hill]

I'll remove this scenario.

[davidsauntson]

👍🏻