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

chore(Avatar) update tests to new standarts #7829

Merged
merged 3 commits into from
Sep 1, 2022

Conversation

Dominik-Petrik
Copy link
Contributor

What: Closes #7812

@patternfly-build
Copy link
Contributor

patternfly-build commented Aug 12, 2022

Copy link
Contributor

@wise-king-sullyman wise-king-sullyman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is good progress! I have a couple of requests for things I would like to see changed and a handful of requests for additional tests.

Comment on lines 5 to 7
test('renders simple avatar', () => {
render(<Avatar alt="avatar" data-testid="avatar" src="test.png" border="light" />);
expect(screen.getByTestId('avatar')).toBeVisible();
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 how I've been doing the "renders" test myself, but since the purpose of this kind of test is to be a sanity check ensuring that the component renders relying on the component to pass the data-testid is actually not the best approach.

Jeff suggested the approach that I went with in the version of this test in my overflow tab tests PR and I think it would be an improvement here as well.

Comment on lines 10 to 17
test('renders with class name pf-m-light when "light" is passed as border prop', () => {
render(<Avatar alt="avatar" data-testid="avatar" src="test.png" border="light" />);
expect(screen.getByTestId('avatar')).toHaveClass('pf-m-light');
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've gone back and forth a bit with how I feel about testing the different values that can be provided for a prop.

In situations like this prop where the different options are very limited and different classes are applied based on the option used I think each option (and the default behavior) should be tested, i.e. a test that neither class is applied by default, a test that the light class is applied with the light option, and a test that the dark class is applied with the dark option.

Comment on lines 15 to 22
test('renders with class name pf-m-lg when "lg" is passed as size prop', () => {
render(<Avatar alt="avatar" data-testid="avatar" src="test.png" size='lg' />);
expect(screen.getByTestId('avatar')).toHaveClass('pf-m-lg');
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar situation here to the previous comment.

expect(screen.getByTestId('avatar')).toHaveClass('pf-m-lg');
});


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additional things I would like to see tested:

  • That it renders with pf-c-avatar
  • That the className prop functions
  • That the src prop functions
  • That the alt prop functions
  • That non-explicitly declared props (such as aria-label in this case) can be applied as expected
  • A snapshot test of the component to prevent unintended changes of the default behavior

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also one note: typically we want each test to ideally only include props that are either required or under test, so a lot of the props in use in the tests you have here can be removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hopefully all the required changes have been resolved. Thanks for the feedback. I am not quite sure about the way the src test is carried out though, let me know what you think.

Copy link
Contributor

@gitdallas gitdallas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kinda wonder if the snapshot should include several props.. but overall coverage lgtm

Copy link
Contributor

@wise-king-sullyman wise-king-sullyman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is seriously great work 💪 there's only one thing I would like to see changed (though it is repeated in almost all of the tests) and then it should be good to go!

Rather than using

    <div data-testid="avatar">
      <Avatar alt="avatar" />
    </div>

In all tests I would like to see that only used in the first test, because in that first test we're just trying to establish that something is rendered without having to make any other assumptions. Apologies if I was unclear about that.

For all other tests I would like to see getByRole('img') used to query for the component.

<Avatar alt="avatar" />
</div>
);
expect(screen.getByTestId('avatar').firstChild).toHaveClass('pf-c-avatar', { exact: true });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using { exact: true } here was a 🔥 idea and something I'll be doing in the future in similar scenarios!

</div>
);
const image = screen.getByRole('img') as HTMLImageElement;
expect(image.src).toMatch('test.png');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this was a great way of testing that src works properly!

@Dominik-Petrik
Copy link
Contributor Author

kinda wonder if the snapshot should include several props.. but overall coverage lgtm

Hey, I have added a few props to snapshot test in most recent commit.

Copy link
Contributor

@wise-king-sullyman wise-king-sullyman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀 great work on this!

@nicolethoen nicolethoen merged commit d20245f into patternfly:main Sep 1, 2022
@patternfly-build
Copy link
Contributor

Your changes have been released in:

  • eslint-plugin-patternfly-react@4.75.2
  • @patternfly/react-catalog-view-extension@4.87.2
  • @patternfly/react-charts@6.89.2
  • @patternfly/react-code-editor@4.77.2
  • @patternfly/react-console@4.87.2
  • @patternfly/react-core@4.236.2
  • @patternfly/react-docs@5.97.2
  • @patternfly/react-icons@4.87.2
  • @patternfly/react-inline-edit-extension@4.81.2
  • demo-app-ts@4.196.2
  • @patternfly/react-integration@4.198.2
  • @patternfly/react-log-viewer@4.81.2
  • @patternfly/react-styles@4.86.2
  • @patternfly/react-table@4.105.2
  • @patternfly/react-tokens@4.88.2
  • @patternfly/react-topology@4.83.2
  • @patternfly/react-virtualized-extension@4.83.2
  • transformer-cjs-imports@4.74.2

Thanks for your contribution! 🎉

andyyvo pushed a commit to andyyvo/patternfly-react that referenced this pull request Sep 9, 2022
* chore(Avatar) update tests to new standarts

* add more tests

* fix querying components
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Avatar test revamp
5 participants