This project was bootstrapped with Create React App.
In the project directory, you can run:
yarn start
-
Runs the app in the development mode.
Open http://localhost:3000 to view it in the browser.
The page will reload if you make edits.
You will also see any lint errors in the console.
yarn test
- Launches the tests.
yarn run test:watch
- Launches the test runner in the interactive watch mode.
yarn build
- Builds the app for production to the build
folder.
It correctly bundles React in production mode and optimizes the build for the best performance.
The build is minified and the filenames include the hashes.
Your app is ready to be deployed!
See the section about deployment for more information.
Check out structure of the components
folder here.
-
We should make the logic to be more abstract. Lots of our components are tied to specific types, even though we need only a few fields from that type. Later this leads to the point where for example we use discussion messages everywhere and now we have chat messages, the types are different and we should reinvent the wheel to make it working in a kinda good way.
A lot of such code issues are because we do not have enough time, or we didn't know future plans that time. But, anyway, big feature should be written in an abstract way with understanding that it may be extended somehow in the future.
Check out Write stories series of articles on Storybook docs site to understand what is "story" and how to write them. Testing articles will show which kind of tests we can write for our stories.
In our project we put stories next to the component file itself and name it as ComponentName.stories.tsx
.
yarn run storybook
- Runs storybook
yarn run test:storybook
- Runs tests for Storybook stories
yarn run test:snapshots
- Runs snapshot tests for Storybook stories
yarn run update:snapshots
- Updates snapshot tests for Storybook stories
For testing purposes we are using React Testing Library. The main idea of this library is to avoid testing implementation details or testing again the logic of a nested component which already is covered by tests.
️Please read small instruction from the library regarding writing the tests: link 1 and link 2 ❗️️️
Here is a good article about why testing of implementation details is not good.
Of course, sometimes it is necessary to know something about the inner logic and here we can just mock it to use our logic from the tests.
Cases where we need to test calls to BE, test store changing after BE call, test redirecting, etc... is more related to integration tests, which our project doesn't use.
What we should test:
- utils or any helpers we are writing for our components;
- components, which are units on our pages. It is hard to write unit tests for the components which use under the hood some other components and have some logic with those components. To test such components we should use integration tests. But we still can cover by unit tests nested components;
- cases where we use different logic based on user viewport (desktop or mobile);
- reducers.
Create a new file near the file you are going to test. Use the same file name, but add spec
before the extension.
Examples:
formatDate.ts
->formatDate.spec.ts
Button.ts
->Button.spec.ts
If you need to mock something you can create a file in utils/tests and import a newly created file in the setupTests.ts file.
- Check out common-backend repository and follow the
Installation
andpublic Dev env
sections to run the project in the dev mode; - Go to the controller for user creation. Look for the
if
statementprocess.env.NODE_ENV !== 'local'
and removeelse
part, as well asif
check (leave the code which is in thatif
block); - Open package.json file and change
REACT_APP_ENV=dev
toREACT_APP_ENV=local
in thestart
script. yarn start
The documentation is here.