-
Notifications
You must be signed in to change notification settings - Fork 15
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 to check for Clean up button visibility #1629
Conversation
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.
@rtorrero I would go with a new file for the deregistration (deregistration.cy.js
). This topic is so big, and involves more things that a unique file would be better.
Besides this, I miss the fact that we test that the button is there when the heartbeat fails.
I would prefer to have something like
- Heartbeat sending - button is nothere
- Heartbeat stopped - button shows up
- Heartbeat sending again - button goes away
@@ -170,4 +170,42 @@ context('Hosts Overview', () => { | |||
}); | |||
}); | |||
}); | |||
|
|||
describe('Clean-up', () => { |
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.
Maybe Deregistration
?
|
||
it('should hide all Clean-up buttons when heartbeat starts except the first one', () => { | ||
cy.get( | ||
':nth-child(1) > .w-48 > .bg-white > .text-jungle-green-500' |
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.
What about this: tr:nth-child(1) > td:nth-child(9)
where the 1st 1
is the row number.
The other query selector looks totally confusing
}); | ||
|
||
it('should remove a host after confirming host cleanup', () => { | ||
cy.get('.bg-jungle-green-500').click(); |
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.
This test depends in the previous one. The test should be executable by itself, so it should set the host in deregisterable state, open the modal, and everything else.
); | ||
}); | ||
|
||
it('should remove a host after confirming host cleanup', () => { |
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.
Cannot we get the button by name of something? The class usage looks weak and really not meaningful
Hey @arbulu89, thanks for the quick review :-)
I'm not sure about this: up until now, we have organized all the tests by section / view:
I'd find it confusing to mix these and now introduce splitting by "feature" Also, organizing the test files by section / view reduces the total run time of the e2e test suite as it minimizes transitioning from one part of trento to a different one (the deregistration / cleanup feature spans through multiple views). We would check the cluster details view for the cluster details specific tests and then we'd need to navigate again to it while running the deregistration tests) I'd instead use http calls to our backend in the views that are affected by the deregistration (e.g. cluster details) to deregister a single host and, while I'd use the button in those views that have it.
I was indeed doing this but as you said, depending on the previous test. I'll improve this and to it explicitly as you suggest, being able to run tests independently is indeed important. |
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.
Some additional comments from my side
@@ -30,7 +30,12 @@ function DeregistrationModal({ | |||
onClick={onCleanUp} | |||
> | |||
<EOS_CLEANING_SERVICES size="base" className="fill-white inline" /> | |||
<span className="text-white text-sm font-bold pl-1.5">Clean up</span> | |||
<span | |||
id="cleanup-confirm" |
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.
This is just for testing?
You should maybe use data-testid
i guess
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 know the click
event will bubble up to the button
element, so it still works, but isn't it more proper to place this ID on the button
?
In any case, the ID for testing might not even be required, in previous tests we selected the confirm clean up button like this:
screen.getAllByRole('button', { name: 'Clean up' })[1]
web/assets/js/components/HostsList.test.jsx
Line 173 in 73f91dc
const cleanUpModalButton = screen.getAllByRole('button', { |
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.
@jamie-suse That seems from react's testing library, not sure if I can use it in cypress. In any case, based on the official docs https://docs.cypress.io/guides/references/best-practices, data-cy
seems to be the preferred way.
edit: or data-test or data-testid
cy.task('startAgentHeartbeat', heartbeatTargets); | ||
}); | ||
|
||
it('should hide all Clean-up buttons when heartbeat starts except the first one', () => { |
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 personally still don't like this testing approach.
I don't really think we should use so many agents. I would prefer to use one/two agent, and test thing more thorougly.
As commented, a thing that I would do is:
- Send heartbeat for this agent. Check button is not there
- Stop sending hearbeat. Check the button shows up. This is the most important test. I know that it takes time (10 seconds) to reach the heartbeat failed scenario, but otherwise we are not testing this explicitily
- Send hearbeat again and check button goes away
const heartbeatTargets = agents(); | ||
const failingHost = heartbeatTargets.shift(); | ||
before(() => { | ||
cy.task('startAgentHeartbeat', heartbeatTargets); |
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.
Shouldn't we navigate to the hosts view here?
I know that we do in the main beforeAll
, but if we don't do it here, we are already basing our tests in the order of things. For example, before this describe we have the healthDetection
tests, and these tests would already be affected by those.
What do you think?
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.
Good point @arbulu89 I guess that if any of the previous tests would do a cy.visit(...)
it could break. I'll add a
cy.visit('/hosts');
cy.url().should('include', '/hosts');
Maybe for a future PR we could change the top before()
for a beforeEach()
so that this URL visit/check is performed for all tests without having to add it explicitly
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.
Looks good @rtorrero
I wouldn't add the photofinish new feature if it is not used in the tests.
I understand that you added because you were using it locally for your development
@@ -170,4 +170,64 @@ context('Hosts Overview', () => { | |||
}); | |||
}); | |||
}); | |||
|
|||
describe('Deregistration', () => { | |||
const host = { |
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.
Maybe we could call this hostToDeregister
. But not a big deal
.photofinish.toml
Outdated
@@ -202,3 +202,13 @@ files = [ | |||
files = [ | |||
"./test/fixtures/scenarios/host-details/9cd46919-5f19-59aa-993e-cf3736c71053_cloud_discovery_unknown.json", | |||
] | |||
|
|||
[vmdrbddev01] |
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.
This is not used anywhere.
I would avoid adding things that you only use locally for your tests.
If you need in reallity, just add in the corresponding PR
828a186
to
a2521c5
Compare
Description
This PR simply adds: