2021-05-06 11:02:56
Вообще, jest вижу на сегодня почти как стандарт в индустрии юнит тестирования. Не обязательно его использовать с react.
Плюсы - отличная документация, большие возможности
Минусы - слишком жирный тесты запускаются медленно, но прогоняются быстро.
Конкретно в данный момент, пишу тесты на jest для работы с датами (у нас legacy библиотека, известная всем кто работал с датами - moment).
пример теста:
```
describe(`Group by ${GroupByPeriod.
DAY}`, () => {
it(`dayOfYear 68 (2021-03-09)`, () => {
const pickerRange = {
startsAtUTC: '2021-03-08T21:00:00.000Z',
endsAtUTC: '2021-05-05T20:59:59.999Z',
};
const p = {
...params,
payload: {
employeeId: 'employee-1',
period: GroupByPeriod.
DAY,
startsAt: '2021-03-09',
...pickerRange,
},
};
const expected = {
employeeId: p.payload.employeeId,
startsAtForDict: p.payload.startsAt,
startsAt: pickerRange.startsAtUTC,
endsAt: '2021-03-09T20:59:59.999Z',
};
expect(
makeStartEndDatesWithTimeZone(p)).toEqual(expected);
});
});
```
Как видите, никакого "реакта" тут нет. Все тесты всегда сводятся к тому, что мы запустили настоящую функцию (в моем случае
makeStartEndDatesWithTimeZone) и ждем ожидание (expected).
Если вы не пишите юнит-тесты, то я очень советую разобраться. Так как научиться недолго, а времени экономит уйму. Причем не только вам, но и вашим коллегам.
если перевести на русский, в тесте выше я проверяю, что дата старта и дата окончания, то что я ожидаю.
---
Итого:
Разница между тестом expect(add(1,3)).toBe(4) (якобы тестируем функцию сумма (add)) и портянкой выше, лишь в том, что у меня "ожидание" расписано в несколько строк. Отсюда можно сделать вывод, что сам по себе юнит-тест, это легкая конструкция. Обычно все проблемы только с первичной настройкой.
923 viewsedited 08:02
M
