Skip to content
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

Merged
merged 6 commits into from
Jul 19, 2023

Conversation

rtorrero
Copy link
Contributor

@rtorrero rtorrero commented Jul 13, 2023

Description

This PR simply adds:

  • e2e test to check if the "Clean up" button in the hosts overview is only displayed after a failed heartbeat
  • e2e test to check if the "Clean up" button displays a confirmation and removes the host after confirmation

@rtorrero rtorrero added javascript Pull requests that update Javascript code test labels Jul 13, 2023
@rtorrero rtorrero marked this pull request as ready for review July 13, 2023 12:02
Copy link
Contributor

@arbulu89 arbulu89 left a 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', () => {
Copy link
Contributor

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'
Copy link
Contributor

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();
Copy link
Contributor

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', () => {
Copy link
Contributor

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

@rtorrero
Copy link
Contributor Author

Hey @arbulu89, thanks for the quick review :-)

@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.

I'm not sure about this: up until now, we have organized all the tests by section / view:

  • about
  • checks_catalog
  • clusters_overview
  • ... etc

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.

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

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.

Copy link
Contributor

@arbulu89 arbulu89 left a 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"
Copy link
Contributor

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

Copy link
Contributor

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]

const cleanUpModalButton = screen.getAllByRole('button', {

Copy link
Contributor Author

@rtorrero rtorrero Jul 17, 2023

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', () => {
Copy link
Contributor

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:

  1. Send heartbeat for this agent. Check button is not there
  2. 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
  3. Send hearbeat again and check button goes away

const heartbeatTargets = agents();
const failingHost = heartbeatTargets.shift();
before(() => {
cy.task('startAgentHeartbeat', heartbeatTargets);
Copy link
Contributor

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?

Copy link
Contributor Author

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

test/e2e/cypress/e2e/hosts_overview.cy.js Show resolved Hide resolved
test/e2e/cypress/e2e/hosts_overview.cy.js Outdated Show resolved Hide resolved
@rtorrero rtorrero requested review from jamie-suse and arbulu89 July 18, 2023 12:53
Copy link
Contributor

@arbulu89 arbulu89 left a 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 = {
Copy link
Contributor

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

@@ -202,3 +202,13 @@ files = [
files = [
"./test/fixtures/scenarios/host-details/9cd46919-5f19-59aa-993e-cf3736c71053_cloud_discovery_unknown.json",
]

[vmdrbddev01]
Copy link
Contributor

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

@rtorrero rtorrero force-pushed the add-e2e-cleanup-button-test branch from 828a186 to a2521c5 Compare July 19, 2023 07:34
@rtorrero rtorrero merged commit da55221 into main Jul 19, 2023
@rtorrero rtorrero deleted the add-e2e-cleanup-button-test branch July 19, 2023 08:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
javascript Pull requests that update Javascript code test
Development

Successfully merging this pull request may close these issues.

3 participants