-
Notifications
You must be signed in to change notification settings - Fork 8
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
Add test for language slug in metadata feature #1637
base: master
Are you sure you want to change the base?
Conversation
HI @shubham1g5, apologies for the delay in getting this up! I made the mistake of trying to model it after the WindowWidth test which led me astray. I'm still not sure about how valid this test is given that it feels a bit heavy handed (having to manually set the GlobalLocalizer's available locales and current locale). I wrote it in the description too but this does indeed test the ability to access the localizer's locale through that specific xpath which I think is enough but wanted to get your thoughts on it. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1637 +/- ##
============================================
+ Coverage 70.22% 70.29% +0.07%
- Complexity 2003 2008 +5
============================================
Files 254 254
Lines 7899 7911 +12
Branches 742 744 +2
============================================
+ Hits 5547 5561 +14
+ Misses 2070 2067 -3
- Partials 282 283 +1 ☔ View full report in Codecov by Sentry. |
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.
@minhaminha I think the way we want to write these tests is by using the changeLanguage
calls like here. We should not really need to make a change in any bean models. The big difference between windowWidth
and locale
here is that HQ conveys FP the windowWitdth
in the request payload while locale
is already stored and maintained on FP side with HQ only needing to convey the local changes on browser side by using the /change_locale
endpoint on FP. Let me know if I should provide any more details here and thanks for following up with tests!
@shubham1g5 all the bean changes are so that |
@minhaminha Is there an app I can see this feature working ? I want to cross check the behaviour you are seeing in the tests with the actual feature behaviour. Update: That I tried this on my end by displaying the value of the session variable here but when I go the form and change the language to any other language, this doesn't really update the the new changed language both in the label display and when using the evaluate Xpath to calculate value of |
Technical Summary
This is a followup PR to this one, which allows for the current screen's language slug to be accessible through the session metadata. This just adds a test to cover that area.
Safety Assurance
Safety story
This only adds a test and test-specific code blocks to existing functions.
evaluateXpath
is currently written to initialize the session locales every time it's called (at least test-specific scenarios) which makes it necessary to manually globalLocalizer's available and default locales, because the test is looking to verify that that value can be accessed through theapplanguage
xpath,Automated test coverage
The whole PR is the test coverage.
Special deploy instructions
Rollback instructions
Review