33 Matching Annotations
  1. Sep 2021
  2. Sep 2020
  3. Apr 2020
    1. We really only need to test that the button gets rendered at all (we don’t care about what the label says — it may say different things in different languages, depending on user locale settings). We do want to make sure that the correct number of clicks gets displayed

      An example of how to think about tests. Also asserting against text that's variable isn't very useful.

  4. Dec 2019
    1. Various test runners support using compiled webpack code to drive tests, but may be difficult to integrate with webpack, and Neutrino helps alleviate this
  5. 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. 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.
  6. Sep 2018
  7. Apr 2016
    1. Brief but useful contrast of Jest vs. Angular approaches to dependency injection.

      The argument is that most code uses one implementation in production and one mock in testing and that using require() as the seam for inserting test doubles makes code easier to write than Angular's approach of implementing its own module system and DI container.

  8. Feb 2016
    1. I'm not sure I like the requirement to use classes but some interesting notes on dependency injection for JS