сколько ui компонентов, функций нужно покрывать тестами, типа не все тестами крыть, а наверное только те места, которые потенциально могут сломаться?
Интерестно ваш опыт и мысли послушать
почему, хочешь ставь coverage 100% и покрывай всё)
Чел тебе говорит Фух, я за 3 дня столько функционала реализовал, все дедлайны прошел, допилил то что раньше оставлял на потом А ты такой Ну пук среньк зато я каждый компонент покрыл тестати я молодец, правда щас не спать не кушать 2 дня, ибо все просрочил ничего не успел но ничего страшного 👉👈
честного говоря на написании тестов достаточно быстро рука набивается
Ну да с опытом быстрее все это делаешь, но все равно же нужно знать эту черту и не тратить на тесты ненужное кол-во времени, понятно что это с опытом приходит скок на это нужно тратить и вот интерестно мнение людей послушать)
я думаю ты попадешь на проект где уже за тебя более опытные люди решат какой нужен coverage
Однозначно тестами покрываются вспомогательные модули/самописные утилиты, где есть какое-то преобразование и тд т.к. при обильном и частом использовании компонента выскакивает большое кол-во козявок и недоработок. Есть визуальные баги, которые я точно не могу сказать как ловить, кроме как ручного тестирования или пошаговой проверки отрисовки. Ну и бизнес-логика, естественно) Если пилишь serverless, то будет больно, а так тесты на такое помогут сократить ошибки и проблемы тестировщикам/разрабам. Особенно интересен TDD-подход Больше пока не опишу
Это то понятно, но хочется все равно сейчас начинать понимать разбирать в этом
пробуй 90% тогда) оставь пространство для маневра на сложных кейсах)
а как же тогда реализовать добавление через редусер, я просто через useState разобрался: const handelAddTask = () => { const newTask = { text: '', check: 'false', id: new Date(), } newTask.text = (prompt()); setTask([...listTask, newTask]); } подумал что через редусер аналогично.
Обсуждают сегодня