-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent government_frontend test failure if meta tag key doesn't exist #3741
Conversation
ec0bf71
to
5017ee4
Compare
5017ee4
to
8ca006a
Compare
7c926d9
to
865c507
Compare
865c507
to
bec5425
Compare
bec5425
to
2803945
Compare
2803945
to
a14a2c4
Compare
a14a2c4
to
5b49413
Compare
This change also fixes issues with tests by overriding/deleting content item values instead of trying to merge hashes together. Values that existed in the content_item were not being overwritten in our merge. This surfaced some issues with the tests overall. Fixing this led to cleaner/simpler code.
5b49413
to
d430dad
Compare
if government_title && !government[:details][:current] | ||
meta_tags["govuk:ga4-publishing-government"] = government_title | ||
current_government = government.dig(:details, :current) | ||
unless current_government |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm struggling to get my head round this a bit so bear with me. This seems like quite a significant change? It used to always set the ga4-political-status
meta tag (either to political or historic) but now it seems like it might not set it at all, if there's a current_government
. And it can only ever be historic
, not political
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@andysellick The PAs wanted this meta tag to show on "This was published by X government" pages, and that only appears if the page was not created during the current government. If the page was written during the current government you get the "political" value, but if it was published by a previous government, it gives "historic". I had a test which was meant to check the meta tag doesn't render for the current government previously, but it was passing due to the false positive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, sorry, just a bit confused. I can see that ga4-political-status
gets set to historic
on line 99, but where does it get set to political
? Does that come directly from the content somehow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@andysellick No worries - It no longer gets set to political
at all with this change since that's only relevant for pages that are published during the current government. Because the PAs have only requested to have the information of previous governments I have removed it from being set.
Political would get set if current
is true
for the government in the content item. In the old meta tag, it was setting the meta tag to political
based on that:
if details[:political]
political_status = details[:government][:current] ? "political" : "historic"
end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah okay that's clarified things. Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still not sure I fully understand this change, but I'm reassured that the worst that can happen is that the status of some pages might be misreported in the analytics data.
@@ -92,13 +92,12 @@ def add_political_tags(meta_tags) | |||
def add_ga4_political_tags(meta_tags) | |||
government = content_item.dig(:links, :government, 0) | |||
|
|||
# political: true/false is in a different place to current: true/false, which is why we have 'details' and 'government[:details]' | |||
# political: true/false is in a different place to current: true/false, which is why we have 'details' and 'government.dig(:details)' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this comment still relevant? I'm not sure what it means.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@andysellick Populating the meta tag relies on two values existing:
details[:political]: (true/false)
government[:details][:current]: (true/false)
And the comment was trying to explain why the code is referring to two different details
objects.
What
government[:details][:current]
government_frontend
tests generate random but valid schemas to test against. Therefore, the test schema sometimes would contain thegovernment
object, but thegovernment
object wouldn't contain[:details][:current]
and therefore crash.government_frontend
is:application.html.erb:63
was the call to rendermeta_tags.html.erb.
ingovernment-frontend
. I used puts statements withinmeta_tags.rb
in this repo to determine which line in our GA4 meta tag code was crashing during thegovernment-frontend
test..dig
in Ruby instead, which will returnnil
instead of crashing if the key doesn't exist.government_frontend
against this local branch, and forced the test to give me the same erroring content schema each time (instead of giving random ones) and thegovernment-frontend
test passes now. I also tested it multiple times against random schemas and have not experienced any test failures..merge
to try and remove values in the existing content item, but this was actually not working reliably. Therefore it was better to use.delete
when removing values, and to just override keys that needed changing. This surfaced some issues with the meta tag code which are now fixed, and the code is simpler as a result.Why
government-frontend
, because the tests check randomly generated but valid content schemas (that are different to ones on production), so some schemas didn't have the right data we needed and therefore the tests would fail when encountering that version of a schema.Visual Changes
None.