35 Matching Annotations
  1. Jan 2022
  2. Oct 2020
    1. You want to write maintainable tests that give you high confidence that your components are working for your users. As a part of this goal, you want your tests to avoid including implementation details so refactors of your components (changes to implementation but not functionality) don't break your tests and slow you and your team down.

      key point. I think that this also means that NOT using data-testid is better since this is "testing library" specific attribute and 'binds' us to testin-library

    1. we are using RTL's findBy search variant to wait for element(s) which appear eventually.

      see above - this is how you'd wait async to grab the element you need

    2. For any element that isn't there yet but will be there eventually, use findBy over getBy or queryBy. If you assert for a missing element, use queryBy. Otherwise default to getBy

      key point: summary of getBy, queryBy and findBy

    3. The neat thing about getByRole: it shows all the selectable roles if you provide a role that isn't available in the rendered component's HTML:

      pass no arguments and it will list all available roles in the element you passed to it (including implicit roles)

    4. // recommended

      notice that this is the recommended practice

    5. Whereas the describe-block is the test suite, the test-block (which also can be named it instead of test) is the test case. A test suite can have multiple test cases and a test case doesn't have to be in a test suite. What you put into the test cases are called assertions (e.g. expect in Jest) which either turn out to be successful (green) or erroneous (red). Here we have two assertions which should turn out successful:

      Key point explaining key basic terms in React testign world

  3. Dec 2019
  4. Nov 2019
    1. Since the checkbox is rendering an input I would work with it rather than focusing on the image. You could do something like this: const checkbox = getByTestId('checkbox-1234').querySelector('input[type="checkbox"]') expect(checkbox).toHaveProperty('checked', true)
    2. the way Material UI works is it renders a different SVG when the checkbox is clicked, and not changing the attributes or anything on the actual input element. So how do I actually test that the element is checked in line with the react-testing-library philosophy?

      These tags belong to entire page. This quote is just supporting evidence for the tags.

    1. Tests implementation details a bit (child component props received), but pretty good other than that.

      https://www.robinwieruch.de/react-testing-tutorial, for example, says that is reasonable to do:

      an integration test could verify that all necessary props are passed through from the tested component to a specific child component.

    1. Here are my tools of choice for testing React apps:react-test-renderer for snapshot unit testingAct API for unit testing React componentsJest for unit and integration testing of JavaScript codeCypress for end to end / ui testing
    1. I don't recommend unit testing stateful components, or components with side-effects. Write functional tests for those, instead, because you'll need tests which describe the complete end-to-end flow, from user input, to back-end-services, and back to the UI. Those tests frequently duplicate any testing effort you would spend unit-testing stateful UI behaviors. You'd need to do a lot of mocking to properly unit test those kinds of components anyway, and that mocking may cover up problems with too much coupling in your component.
    1. Snapshot Test: Introduced by Facebook’s library Jest, Snapshot Tests should be the lightweight variation of testing (React) components. It should be possible to create a DOM snapshot of a component once a test for it runs for the first time and compare this snapshot to a future snapshot, when the test runs again, to make sure that nothing has changed. If something has changed, the developer has to either accept the new snapshot test (the developer is okay with the changes) or deny them and fix the component instead.
  5. Oct 2019
  6. Dec 2018
  7. Sep 2018