Explicit move to Applications Enabled page #1432
Conversation
The test suite expect the product be on Applications Enabled page. Starting with RHOAI 2.10, we can have a new home page.
|
Robot Results
|
| @@ -80,6 +80,7 @@ Login To RHODS Dashboard | |||
| IF ${login-required} Login To Openshift ${ocp_user_name} ${ocp_user_pw} ${ocp_user_auth_type} | |||
| ${authorize_service_account}= Is rhods-dashboard Service Account Authorization Required | |||
| IF ${authorize_service_account} Authorize rhods-dashboard service account | |||
| Navigate To Page Applications Enabled | |||
There was a problem hiding this comment.
this is temporary right? we should check later that user ends up on the new home page
There was a problem hiding this comment.
The current test suite is expecting that. We just explicitly/write the code.
When we have a new home page we have two options:
- rewrite the test suite in order to not expect the Enabled page by default
- have a different test only for home page
There was a problem hiding this comment.
hm as far as I remember, tests use Wait For RHODS Dashboard To Load which allows you to set the expected page. So the tests don't wait explicitly for "Enabled" page, unless there are tests doing it explicitly, but don't know for sure
I found a dedicated discussion in Slack, let me go through it
There was a problem hiding this comment.
set the expected page
yes. but by default it is the Enabled
So the tests don't wait explicitly for "Enabled" page
they explicitly are expecting the Enabled page because of the login method
There was a problem hiding this comment.
Later, yes. And I prefer not to have a default value.
There was a problem hiding this comment.
So... is the time to revert this finally?
There was a problem hiding this comment.
Suppose you are going to change something related to this code. Please make sure you do it explicitly.
In this case, if we read the code we know exactly what is happening.
There was a problem hiding this comment.
Yeah, I bumped into this when reviewing failures of some of our tests. I have two options basically:
- provide a bit ugly and easy solution (at least from my point of view) to change a couple of our tests only
- revert this workaround and check that no tests are broken which is much more work - but seem like a proper solution for me
And I would prefer to avoid both of the above of course... 🙃
This started failing after this workaround red-hat-data-services#1432 ([1]). Originally the test expected that after logout and another login, the user is redirected to the original page where logout started. This doesn't happen anymore because of this new redirect to `enabled` paged in the mentioned workaround. Once the workaround is removed, we can delete the line added in this PR also. Though, the main point of the test isn't to check where the page is open after login, but the actual login names work as expected only. * [1] f9dfc88
This started failing after this workaround #1432 ([1]). Originally the test expected that after logout and another login, the user is redirected to the original page where logout started. This doesn't happen anymore because of this new redirect to `enabled` paged in the mentioned workaround. Once the workaround is removed, we can delete the line added in this PR also. Though, the main point of the test isn't to check where the page is open after login, but the actual login names work as expected only. * [1] f9dfc88
This started failing after this workaround red-hat-data-services#1432 ([1]). Originally the test expected that after logout and another login, the user is redirected to the original page where logout started. This doesn't happen anymore because of this new redirect to `enabled` paged in the mentioned workaround. Once the workaround is removed, we can delete the line added in this PR also. Though, the main point of the test isn't to check where the page is open after login, but the actual login names work as expected only. * [1] f9dfc88
This removes the workaround added in [1,2] and expects the default dashboard page to be the landing/home page now. [1] red-hat-data-services#1432 [2] f9dfc88
This removes the workaround added in [1,2] and expects the default dashboard page to be the landing/home page now. [1] red-hat-data-services#1432 [2] f9dfc88
The test suite expect the product be on Applications Enabled page. Starting with RHOAI 2.10, we can have a new home page.
Jenkins: rhods-smoke/5371/