following by #34 we decided to add comments inside all "don't" examples. it'd help your readers to understand better the main idea for each section.

Agenda

• Create our roadmap.
• Make a decision: Enzyme vs React Testing Library. #3

Actions

• Act - https://reactjs.org/docs/testing-recipes.html - Make a research about ACT pattern in context to react and RTL. Obviously, go through the whole testing recipes.
• Snapshots - Do we want to recommend using snapshots?
• Create 3 types of tests So we can compare RTL and Enzyme well. ( Container, FnComponent, ClassComponent).

These are the issues we raised during this meeting:

• Think about adding backend orientation to the style guide
• Talk about BDD in the basic rules (how we write assertions)
• Opinion about snapshots
• Talk about TDD or just mention it
• Visual testing
• What do we say about coverage
• Should we talk about linters?
• We're talking very shortly about E2E
• Act in React and async side effects shouldn't be in the basic rules imo
• Should we test selectors, reducers?
• The E2E diagram should be revisited for UX manners.
• There's missing information about E2E, why we do it and how
• In the bad examples - Add comments inside the code
• What are our thoughts about getByText? (Translation related)

Participants:
@lidoravitan @einatnielsen @liadShiranNielsen @MatanBorenkraoutNielsen

Cons:

• Failures are hard to understand (It’s often hard to see what changed by looking at the snapshot failure diff)
• We tend to update snapshots without thinking
• Easy to commit snapshots with bugs (since we usually don’t read these files carefully)
• Coupling with low level modules (if you don’t use shallow rendering)
• A false sense of security (Snapshots offer no guarantees that component appearance or behavior is correct)
• FB recommends using more specific assertions than using snapshots here

Agenda

• Talk about data attributes - Explanation here

• Snapshots - Nik will show an example explaining his approach to snapshots

• AAA - Update on current progress - Issue

• Class component - Update on current progress

• Page Object Pattern

Agenda

• https://reactjs.org/docs/testing-recipes.html - make a research about Act pattern in context to React and RTL. Obviously, go through the testing recipes.

• Snapshots - Do we want to encourage using snapshots? #6

• POC - FnComponent, ClassComponent and Redux Connected Component with RTL.

  • Functional Component - Gist
  • Class Component - Gist
  • Redux Connected Component - Gist

internationalization and localization are means of adapting application to different languages. in context to front-end development it could be internal implementation or 3rd party package. However, In terms of testing we want to explain what're the guidelines to test i18n case.

usually i18n implementation is key/value map for each language, which means inside components we use keys to render reach static text instead of write the actual text. for example:

without i18n:<div>hello world </div>
with I18n: <div>formatMessage('examples.hello.world')</div>

References
https://testing-library.com/docs/example-react-intl

Agenda

• https://reactjs.org/docs/testing-recipes.html - make a research about Act pattern in context to React and RTL. Obviously, go through the testing recipes.

• Snapshots - Do we want to encourage using snapshots? #9

Agenda

• Sync for the last action items
  Add mocks and spy guidelines - @MatanBorenkraoutNielsen #17,#18
  Add Redux guidelines - @lidoravitan #15

• Getting ready to release.

This issue is related to the Arrange - Act - Assert principal and especially in React using the act function

Add an example of how to test reducers, selectors and actions.
you can take examples from Redux recipes

Agenda

Make a decision about our Repo responsibilities.

Actions

Make a research for Enzyme vs React Testing Library.

• Open Trello - Matan
• Create Meetings template - Einat (ex resource: nodejs/website-redesign#164)
• Align current repo - Lidor

Is it me, or Do and Don't sections are mixed up in here? https://github.com/nielsen-oss/docs/tree/master/javascript/testing#redux-connected-component

Currently it says one should mock action creators instead of verifying result in DOM.

The purpose of this issue is to review the pros and cons between Enzyme and React Testing Library.

• For the purpose of this discussion we will refer to React Testing Library as RTL.

RTL Pros:

1. RTL is built on top of react-dom and react-dom/test-utils, thus supports new React features out of the box
2. RTL approach is testing user behaviour which leads you to be more confident in your tests
3. RTL limits the way you can interact with elements, and thus forces you to write code that is a11y compliant (best practice).
4. FB recommend using RTL

Enzyme Cons:

1. Enzyme is built on top of a custom 'react-dom', thus supporting React new features will not be out of the box
2. Enzyme unit testing makes you lean towards testing implementation details (state and props) which your user does not care.
3. Enzyme encourage using ID and css selector, by that your tests are likely to break when you refactor.

Add an example of how to test components that have timers in them,
this can be based on the jest useFakeTimers approach here

currently, we say that hook testing is not preferred but component testing should test it along the way instead. this is true for an internal hook for the sake of the component.

however, when the hook is to be shared across components, it should be tested in isolation as a standalone hook and it is the best practice

We need to cover e2e testing approaches in the style guide.

The explanation should mainly be about how we use the Page Object pattern to interact with the tested page and include code examples of a test that uses a Page Object.
In addition, we need to explain concepts like flows and selectors and how they fit into the e2e testing approach.

The examples should show how we use cypress for e2e tests.

Agenda

Round Table
we want to involve the group with the testing style guide initiative. First, we want to share our knowledge with the group. second, we want to encourage the group to contribute.

actions

1. determine the responsibilities and goals for this repo in our group.
2. pick a date :).
3. create a presentation.

We already know agree snapshot testing are totally ok. however, there are only few cases we want to encourage them. let's add extensive exploration about snapshot testing. #34