Introduction to React Testing: Remove unnecessary mention of FireEvent

react/react_testing/introduction_to_react_testing.md

@@ -16,23 +16,17 @@
 
 Phew, that was a lot of setup. But there's one more tiny package to install before we can begin:
 
 ```
 npm install @testing-library/user-event --save-dev
 ```
 
 Now that we have everything we need, let's briefly go over what some of those packages do. We'll primarily focus on the `@testing-library` packages. 
 
 * `@testing-library/react` will give us access to useful functions like `render` which we'll demonstrate later on.
 
 * `@testing-library/jest-dom` includes some handy custom matchers (assertive functions) like `toBeInTheDocument` and more. (complete list on [jest-dom's github](https://github.com/testing-library/jest-dom)). Jest already has a lot of matchers so this package is not compulsory to use. 
 
-* <span id="user-event">`@testing-library/user-event` provides the `userEvent` API that simulates user interactions with the webpage.</span> Alternatively, we could import the `fireEvent` API from `@testing-library/react`. 
-
-  <div class="lesson-note" markdown="1">
-
-  `fireEvent` is an inferior counterpart to `userEvent` and `userEvent` should always be preferred in practice.
-
-  </div>
+* <span id="user-event">`@testing-library/user-event` provides the `userEvent` API that simulates user interactions with the webpage.</span>
 
 ### Our first query
 
@@ -61,7 +55,7 @@
 
 ```
 
 Execute `npm test App.test.jsx` on the terminal and see the test pass. `getByRole` is just one of the dozen query methods that we could've used. Essentially, queries are classified into three types: `getBy`, `queryBy` and `findBy`. Go through [the React Testing Library docs page about queries](https://testing-library.com/docs/queries/about/). Pay extra attention to the "Types of Queries" and "Priority" sections. 
 
 <span id="by-role-methods">As stated by the React Testing Library docs, `ByRole` methods are favored methods for querying, especially when paired with the `name` option. For example, we could improve the specificity of the above query like so: `getByRole("heading", { name: "Our First Test" })`. Queries that are done through `ByRole` ensure that our UI is accessible to everyone no matter what mode they use to navigate the webpage (i.e. mouse or assistive technologies).</span>
 
@@ -123,11 +117,11 @@
 });
 ```
 
 The tests speak for themselves. In the first test, we utilize snapshots to check whether all the nodes render as we expect them to. In the second test, we simulate a click event. Then we check if the heading changed. `toMatch` is one of the various assertions we could have made. 
 
 It's also important to note that after every test, React Testing Library unmounts the rendered components. That's why we render for each test. For a lot of tests for a component, the `beforeEach` Jest function could prove handy.
 
 Notice that the callback function for the second test is asynchronous. This is because `user.click()` simulates the asynchronous nature of user interaction, which is now supported by the latest version of the testing library's user-event APIs. 
 As of [version 14.0.0](https://github.com/testing-library/user-event/releases/tag/v14.0.0), the user-event APIs have been updated to be asynchronous. It's worth noting that some examples from other resources or tutorials might still use the synchronous `userEvent.click()` method
 
 ```javascript
@@ -146,7 +140,7 @@
 
 ### What are snapshots?
 
 Snapshot testing is just comparing our rendered component with an associated snapshot file. For example, the snapshot file which was automatically generated after we ran the _"magnificent monkeys renders"_ test was:
 
 ```javascript
 // Vitest Snapshot v1, https://vitest.dev/guide/snapshot.html