npm - epam-ai-conductor - Versions diffs - 0.1.0 - Mend

epam-ai-conductor 0.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (115) hide show

package/dist/content/module-5/theory/module-5_react-testing-library_example.md ADDED Viewed

@@ -0,0 +1,379 @@
+---
+sidebar_position: 2
+sidebar_label: 'React Testing Library: Examples'
+title: 'Examples of Tests'
+---
+In this section, you will learn how to render a React component in test with [React Testing Library](https://github.com/testing-library/react-testing-library).
+## Rendering a component
+We will use the following App [function component](https://www.robinwieruch.de/react-function-component/) from a `src/App.js` file:
+```jsx title="src/App.js"
+const title = 'React Testing Library Example';
+function App() {
+  return <div>{title}</div>;
+}
+export default App;
+```
+And test it in a `src/App.test.js` file:
+```jsx title="src/App.test.js"
+import { render } from '@testing-library/react';
+import App from './App';
+describe('App', () => {
+  test('renders App component', () => {
+    render(<App />);
+  });
+});
+```
+The test code above used React Testing Library's `render` method to virtually render the App component imported from `App.js` file and append it to the `document.body` node. You can access the rendered HTML through the `screen` object. This object also has the DOM testing methods already bound into it.
+RTL's render function takes any [JSX](../module-1/jsx.mdx) to render it. Afterward, you should have access to the React component in your test. To convince yourself that it's there, you can use RTL's [debug](https://subscription.packtpub.com/book/web_development/9781800564459/2/ch02lvl1sec14/using-the-debug-method) function:
+```jsx title="src/App.test.js"
+// highlight-next-line
+import { render, screen } from '@testing-library/react';
+import App from './App';
+describe('App', () => {
+  test('renders App component', () => {
+    render(<App />);
+    // highlight-next-line
+    screen.debug();
+  });
+});
+```
+After running your test on the command line, you should see the HTML output of your App component. Whenever you write a test for a component with React Testing library, you can render the component first and then debug what's visible for RTL's renderer in the test. This way, you can write your test with more confidence:
+```html
+<body>
+  <div>
+    <div>
+      React Testing Library Example
+    </div>
+  </div>
+</body>
+```
+The great thing about it, React Testing Library doesn't care much about the actual components. Let's take the following React components which utilize different React features ([useState](../module-1/hooks/useState.md), [event handler](https://www.robinwieruch.de/react-event-handler/), [props]("../module-1/components-and-props.md")) and concepts ([controlled component](https://www.robinwieruch.de/react-controlled-components/)):
+```jsx
+function App() {
+  const [search, setSearch] = React.useState('');
+  function handleChange(event) {
+    setSearch(event.target.value);
+  }
+  return (
+    <div>
+      <Search value={search} onChange={handleChange}>
+        Search:
+      </Search>
+      <p>Searches for {search ? search : '...'}</p>
+    </div>
+  );
+}
+function Search({ value, onChange, children }) {
+  return (
+    <div>
+      <label htmlFor="search">{children}</label>
+      <input
+        id="search"
+        type="text"
+        value={value}
+        onChange={onChange}
+      />
+    </div>
+  );
+}
+export default App;
+```
+If you start the test of your App component again, you should see the following output from the `debug` function:
+```html
+<body>
+  <div>
+    <div>
+      <div>
+        <label
+          for="search"
+        >
+          Search:
+        </label>
+        <input
+          id="search"
+          type="text"
+          value=""
+        />
+      </div>
+      <p>
+        Searches for
+        ...
+      </p>
+    </div>
+  </div>
+</body>
+```
+React Testing Library is used to interact with your React components like a human being. What a human being sees is just rendered HTML from your React components, so that's why you see this HTML structure as output rather than two individual React components.
+## Selecting elements
+Let's learn about how to grab elements which are then used for assertions or for user interactions:
+```jsx
+import React from 'react';
+import { render, screen } from '@testing-library/react';
+import App from './App';
+describe('App', () => {
+  test('renders App component', () => {
+    render(<App />);
+    // highlight-next-line
+    screen.getByText('Search:');
+  });
+});
+```
+And this is an example of the assertion that checks whether the element is in the DOM:
+```jsx
+import React from 'react';
+import { render, screen } from '@testing-library/react';
+import App from './App';
+describe('App', () => {
+  test('renders App component', () => {
+    render(<App />);
+    // highlight-next-line
+    expect(screen.getByText('Search:')).toBeInTheDocument();
+  });
+});
+```
+Conveniently `getByText` throws an error by default if the element cannot be found. This is useful for giving you a hint while writing the test that the selected element isn't there in the first place. A few people exploit this behavior to use search functions like `getByText` as implicit assertion replacement instead of an explicit assertion with expect.
+Most of React test cases should use methods for finding elements. RTL provides you with several methods to find an element by specific attributes in addition to the `getByText()` method above:
+* `getByText()`: find the element by its `textContent` value
+* `getByRole()`: by its `role` attribute value
+* `getByLabelText()`: by its `label` attribute value
+* `getByPlaceholderText()`: by its `placeholder` attribute value
+* `getByAltText()`: by its `alt` attribute value
+* `getByDisplayValue()`: by its `value` attribute, usually for `<input>` elements
+* `getByTitle()`: by its `title` attribute value
+And when these methods are not enough, you can use the `getByTestId()` method, which allows you to find an element by its `data-testid` attribute:
+```jsx
+import { render, screen } from '@testing-library/react';
+render(<div data-testid="test-element" />);
+const element = screen.getByTestId('test-element');
+```
+:::tip
+But since selecting elements using `data-testid` attributes doesn't resemble how a real user would use your application, the documentation recommends you use it only as the last resort when all other methods fail to find your element. Generally, finding by Text, Role, or Label should cover most cases.
+:::
+## Search variants
+One of the search variants in RTL is `getBy` which is used for `getByText` or `getByRole`. This is also the search variant which is used by default when testing React components.
+Two other search variants are `queryBy` and `findBy`; which both can get extended by the same search types that `getBy` has access to. For example, `queryBy` with all its search types:
+* queryByText
+* queryByRole
+* queryByLabelText
+* queryByPlaceholderText
+* queryByAltText
+* queryByDisplayValue
+And `findBy` with all its search types:
+* findByText
+* findByRole
+* findByLabelText
+* findByPlaceholderText
+* findByAltText
+* findByDisplayValue
+### What's the difference between getBy vs queryBy?
+You already know that `getBy` returns an element or an error. It's a convenient side-effect of `getBy` that it returns an error, because it makes sure that we as developers notice early that there is something wrong in our test. However, this makes it difficult to check for elements which shouldn't be there:
+```jsx
+import React from 'react';
+import { render, screen } from '@testing-library/react';
+import App from './App';
+describe('App', () => {
+  test('renders App component', () => {
+    render(<App />);
+    screen.debug();
+    // fails
+    expect(screen.getByText(/Searches for JavaScript/)).toBeNull();
+  });
+});
+```
+This doesn't work, because, even though debug output shows that the element with the text "Searches for JavaScript" isn't there, `getBy` throws an error before we can make the assertion, because it cannot find the element with this text. In order to assert elements which aren't there, we can exchange `getBy` with `queryBy`:
+```jsx
+import React from 'react';
+import { render, screen } from '@testing-library/react';
+import App from './App';
+describe('App', () => {
+  test('renders App component', () => {
+    render(<App />);
+    // highlight-next-line
+    expect(screen.queryByText(/Searches for JavaScript/)).toBeNull();
+  });
+});
+```
+So every time you are asserting that an element isn't there, use `queryBy`. Otherwise default to `getBy`. So what about `findBy` then? The `findBy` search variant is used for asynchronous elements which will be there eventually.
+### What about multiple elements?
+You have learned about the three search variants `getBy`, `queryBy` and `findBy`; which all can be associated with the search types (e.g. Text, Role, PlaceholderText, DisplayValue). If all of these search functions return only one element, how to assert if there are multiple elements (e.g. a list in a React component). All search variants can be extended with the `All` word:
+* getAllBy
+* queryAllBy
+* findAllBy
+Whereas all of them return an array of elements and can be associated with the search types again.
+### Query types summary table
+<table>
+    <thead>
+        <tr>
+            <th>Type of Query</th>
+            <th>0 Matches</th>
+            <th>1 Match</th>
+            <th>&gt;1 Matches</th>
+            <th align="center">Retry (Async/Await)</th>
+        </tr>
+    </thead>
+    <tbody>
+        <tr>
+            <td><strong>Single Element</strong></td>
+            <td></td>
+            <td></td>
+            <td></td>
+            <td align="center"></td>
+        </tr>
+        <tr>
+            <td><code>getBy...</code></td>
+            <td>Throw error</td>
+            <td>Return element</td>
+            <td>Throw error</td>
+            <td align="center">No</td>
+        </tr>
+        <tr>
+            <td><code>queryBy...</code></td>
+            <td>Return <code>null</code></td>
+            <td>Return element</td>
+            <td>Throw error</td>
+            <td align="center">No</td>
+        </tr>
+        <tr>
+            <td><code>findBy...</code></td>
+            <td>Throw error</td>
+            <td>Return element</td>
+            <td>Throw error</td>
+            <td align="center">Yes</td>
+        </tr>
+        <tr>
+            <td><strong>Multiple Elements</strong></td>
+            <td></td>
+            <td></td>
+            <td></td>
+            <td align="center"></td>
+        </tr>
+        <tr>
+            <td><code>getAllBy...</code></td>
+            <td>Throw error</td>
+            <td>Return array</td>
+            <td>Return array</td>
+            <td align="center">No</td>
+        </tr>
+        <tr>
+            <td><code>queryAllBy...</code></td>
+            <td>Return <code>[]</code></td>
+            <td>Return array</td>
+            <td>Return array</td>
+            <td align="center">No</td>
+        </tr>
+        <tr>
+            <td><code>findAllBy...</code></td>
+            <td>Throw error</td>
+            <td>Return array</td>
+            <td>Return array</td>
+            <td align="center">Yes</td>
+        </tr>
+    </tbody>
+</table>
+## Fire event
+We can use RTL's `fireEvent` function to simulate interactions of an end user. Let's see how this works for our input field:
+```jsx
+import React from 'react';
+import { render, screen, fireEvent } from '@testing-library/react';
+import App from './App';
+describe('App', () => {
+  test('renders App component', () => {
+    render(<App />);
+    screen.debug();
+    fireEvent.change(screen.getByRole('textbox'), {
+      target: { value: 'JavaScript' },
+    });
+    screen.debug();
+  });
+});
+```
+The fireEvent function takes an element (here the input field by textbox role) and an event (here an event which has the value "JavaScript"). The debug function's output should show the HTML structure before and after the event; and you should see that the new value of the input field gets rendered appropriately.
+---
+## Materials
+1. [React Testing Library Examples](https://github.com/testing-library/react-testing-library#examples)
+2. [React Testing Library Example: Step-By-Step](https://testing-library.com/docs/react-testing-library/example-intro)
+3. [React Testing Library: Queries](https://testing-library.com/docs/react-testing-library/cheatsheet#queries)
+4. [Firing Events](https://testing-library.com/docs/dom-testing-library/api-events)
+5. [Testing Recipes](https://react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary)

package/dist/content/module-5/theory/module-5_redux-writing-tests.md ADDED Viewed

@@ -0,0 +1,246 @@
+---
+sidebar_position: 4
+sidebar_label: 'Redux. Writing Tests'
+title: Redux. Writing Tests
+---
+The general advice for testing an app using Redux is as follows:
+* Use integration tests for everything working together. I.e. for a React app using Redux, render a `<Provider>` with a real store instance wrapping the component/s being tested. Interactions with the page being tested should use real Redux logic, with API calls mocked out so app code doesn't have to change, and assert that the UI is updated appropriately.
+* If needed, use basic unit tests for pure functions such as particularly complex reducers or selectors. However, in many cases, these are just implementation details that are covered by integration tests instead.
+## Testing Redux connected components
+Let's say we have some components, which fetch user data and display it.
+```jsx
+import React, { useState, useEffect } from "react";
+import { getUserData } from "./api";
+const User = () => {
+  const [userData, setUserData] = useState(null);
+  useEffect(() => {
+    getUserData.then((data) => {
+      setUserData(data);
+    });
+  });
+  if (!userData) {
+    return null;
+  }
+  return <div>{userData.name}</div>;
+};
+export default User;
+```
+Now let's see how it can be tested
+```jsx
+import React from "react";
+import { screen, render } from "@testing-library/react";
+import User from "./User";
+jest.mock("./api", () => ({
+  getUserData: () => ({ name: "mock name" })
+}));
+describe("User", () => {
+  it("should display user name", async () => {
+    render(<User />);
+    const userName = await screen.findByText("mock name");
+    expect(userName).toBeTruthy();
+  });
+});
+```
+The first thing we have to do is mock our API call with `jest.mock`. Normally it would make a network request, but in tests, we need to mock it.
+Then we use `render` function to render our component, and `screen.findByText` to search for text in the component we just rendered.
+Now let's suppose we would need to access user data in other parts of the application. Let's move it to the Redux store. Here is how the refactored version of the component might look like.
+```jsx
+import React, { useState, useEffect } from "react";
+import { connect } from "react-redux";
+import { fetchUserData } from './actions';
+const User = ({ userData, fetchUserData }) => {
+  useEffect(() => {
+    fetchUserData();
+  }, []);
+  if (!userData) {
+    return null;
+  }
+  return <div>{userData.name}</div>;
+};
+const mapStateToProps = (state) => ({
+  userData: state.user
+});
+const mapDispatchToProps = {
+  fetchUserData,
+};
+export default connect(mapStateToProps, mapDispatchToProps)(User);
+```
+Now the first thing you will notice in your test is: **'Could not find "store" in the context of "Connect(User)"'** error. It's because your component needs to be wrapper in `Provider` to access Redux Store. Let's fix our tests:
+```jsx
+import React from "react";
+import { screen, render } from "@testing-library/react";
+import { createStore } from "redux";
+import User from "./User";
+import reducer from "./reducer";
+import store from "./store";
+jest.mock("./api", () => ({
+  getUserData: () => ({ name: "mock name" })
+}));
+const initialState = {
+	user: { name: "mock name" },
+};
+const store = createStore(reducer, initialState);
+const Wrapper = ({ children }) => (
+	<Provider store={store}>{children}</Provider>
+);
+describe("User", () => {
+  it("should display user name", async () => {
+    render(<User />, { wrapper: Wrapper });
+    const userName = await screen.findByText("mock name");
+    expect(userName).toBeTruthy();
+  });
+});
+```
+We fixed the error by creating a Wrapper. This component will wrap the component we test with Provider and apply a mocked state. We can go one step further by custom render function using the one from React Testing Library.
+```jsx
+import React from "react";
+import { render as rtlRender } from "@testing-library/react";
+import { createStore } from "redux";
+import { Provider } from "react-redux";
+import reducer from "./reducer";
+export const renderWithState = (
+  ui,
+  { initialState, ...renderOptions } = {}
+) => {
+  const store = createStore(reducer, initialState);
+  const Wrapper = ({ children }) => (
+    <Provider store={store}>{children}</Provider>
+  );
+  return render(ui, { wrapper: Wrapper, ...renderOptions });
+};
+```
+And then in our case we can just import it and use like this:
+```jsx
+renderWithState(<User />, { initialState });
+```
+## Reducers
+Reducers are simple functions that give you the new state when you apply an action to the current state. Usually, you don't need to test reducers directly unless they have complex logic. But, if you want to be sure your reducer works as expected, testing is straightforward.
+Since reducers are pure functions, testing them is simple. Just call the reducer with a certain starting state and action, then check if the resulting state is what you expect.
+```jsx
+import { createSlice } from '@reduxjs/toolkit'
+const initialState = [
+  {
+    text: 'Use Redux',
+    completed: false,
+    id: 0
+  }
+]
+const todosSlice = createSlice({
+  name: 'todos',
+  initialState,
+  reducers: {
+    todoAdded(state, action: PayloadAction<string>) {
+      state.push({
+        id: state.reduce((maxId, todo) => Math.max(todo.id, maxId), -1) + 1,
+        completed: false,
+        text: action.payload
+      })
+    }
+  }
+})
+export const { todoAdded } = todosSlice.actions
+export default todosSlice.reducer
+```
+We can test it like:
+```jsx
+import reducer, { todoAdded } from './todosSlice'
+test('should return the initial state', () => {
+  expect(reducer(undefined, {})).toEqual([
+    {
+      text: 'Use Redux',
+      completed: false,
+      id: 0
+    }
+  ])
+})
+test('should handle a todo being added to an empty list', () => {
+  const previousState = []
+  expect(reducer(previousState, todoAdded('Run the tests'))).toEqual([
+    {
+      text: 'Run the tests',
+      completed: false,
+      id: 0
+    }
+  ])
+})
+test('should handle a todo being added to an existing list', () => {
+  const previousState = [
+    {
+      text: 'Run the tests',
+      completed: true,
+      id: 0
+    }
+  ]
+  expect(reducer(previousState, todoAdded('Use Redux'))).toEqual([
+    {
+      text: 'Run the tests',
+      completed: true,
+      id: 0
+    },
+    {
+      text: 'Use Redux',
+      completed: false,
+      id: 1
+    }
+  ])
+})
+```
+----
+## Materials
+1. [Redux tests](https://redux.js.org/usage/writing-tests)
+2. [How to test React-Redux connected Components](https://www.robinwieruch.de/react-connected-component-test)

package/dist/content-loader.d.ts ADDED Viewed

@@ -0,0 +1,7 @@
+export declare const TOTAL_MODULES = 5;
+export interface ModuleContent {
+    theory: string;
+    task: string;
+    tests: string;
+}
+export declare function loadModule(n: number): ModuleContent;

package/dist/content-loader.js ADDED Viewed

@@ -0,0 +1,26 @@
+import { readFileSync, readdirSync, existsSync } from 'fs';
+import { join, dirname } from 'path';
+import { fileURLToPath } from 'url';
+const __dirname = dirname(fileURLToPath(import.meta.url));
+const CONTENT_DIR = join(__dirname, 'content');
+export const TOTAL_MODULES = 5;
+function readDir(dir) {
+    if (!existsSync(dir))
+        return '';
+    return readdirSync(dir)
+        .sort()
+        .map(f => {
+        const label = f.replace(/^module-\d+_/, '').replace(/_/g, '/');
+        return `### ${label}\n\n${readFileSync(join(dir, f), 'utf-8')}`;
+    })
+        .join('\n\n---\n\n');
+}
+export function loadModule(n) {
+    const base = join(CONTENT_DIR, `module-${n}`);
+    return {
+        theory: readDir(join(base, 'theory')),
+        task: readDir(join(base, 'task')),
+        tests: readDir(join(base, 'tests')),
+    };
+}
+//# sourceMappingURL=content-loader.js.map

package/dist/content-loader.js.map ADDED Viewed

@@ -0,0 +1 @@

+ {"version":3,"file":"content-loader.js","sourceRoot":"","sources":["../src/content-loader.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,YAAY,EAAE,WAAW,EAAE,UAAU,EAAE,MAAM,IAAI,CAAC;AAC3D,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE,MAAM,MAAM,CAAC;AACrC,OAAO,EAAE,aAAa,EAAE,MAAM,KAAK,CAAC;AAEpC,MAAM,SAAS,GAAG,OAAO,CAAC,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC;AAC1D,MAAM,WAAW,GAAG,IAAI,CAAC,SAAS,EAAE,SAAS,CAAC,CAAC;AAE/C,MAAM,CAAC,MAAM,aAAa,GAAG,CAAC,CAAC;AAQ/B,SAAS,OAAO,CAAC,GAAW;IAC1B,IAAI,CAAC,UAAU,CAAC,GAAG,CAAC;QAAE,OAAO,EAAE,CAAC;IAChC,OAAO,WAAW,CAAC,GAAG,CAAC;SACpB,IAAI,EAAE;SACN,GAAG,CAAC,CAAC,CAAC,EAAE;QACP,MAAM,KAAK,GAAG,CAAC,CAAC,OAAO,CAAC,cAAc,EAAE,EAAE,CAAC,CAAC,OAAO,CAAC,IAAI,EAAE,GAAG,CAAC,CAAC;QAC/D,OAAO,OAAO,KAAK,OAAO,YAAY,CAAC,IAAI,CAAC,GAAG,EAAE,CAAC,CAAC,EAAE,OAAO,CAAC,EAAE,CAAC;IAClE,CAAC,CAAC;SACD,IAAI,CAAC,aAAa,CAAC,CAAC;AACzB,CAAC;AAED,MAAM,UAAU,UAAU,CAAC,CAAS;IAClC,MAAM,IAAI,GAAG,IAAI,CAAC,WAAW,EAAE,UAAU,CAAC,EAAE,CAAC,CAAC;IAC9C,OAAO;QACL,MAAM,EAAE,OAAO,CAAC,IAAI,CAAC,IAAI,EAAE,QAAQ,CAAC,CAAC;QACrC,IAAI,EAAI,OAAO,CAAC,IAAI,CAAC,IAAI,EAAE,MAAM,CAAC,CAAC;QACnC,KAAK,EAAG,OAAO,CAAC,IAAI,CAAC,IAAI,EAAE,OAAO,CAAC,CAAC;KACrC,CAAC;AACJ,CAAC"}

package/dist/context-builder.d.ts ADDED Viewed

	@@ -0,0 +1,2 @@
1	+ export declare const MODULE_TITLES: Record<number, string>;
2	+ export declare function buildContext(moduleNum: number, targetDir: string): void;