Comments 13
Подержите мое пиво!
Не пишу никаких текстов вообще, уже года 4. Просто не вижу в этом смысла. Пока я пишу код, у меня открыт браузер и я сразу проверяю работу. Потом деплой, автотесты, ручное тестирование тестировщиками и нт. Если какой-то баг и закрался — найдут пользаки в проде, а правка дело плевое. Вообще не понимаю зачем тратить время на попытки сэмулировать браузер в ноде и что-то там тестировать. Как-то начал еще playwrite тесты писать, но потом и их выкинул.
У тебя наверное проект в 1 страницу. Любой большой проект старше пары лет начинает превращаться в "подкрутил гайку на руле - отвалилось колесо" без тестов. И ты уже тратишь больше времени на починку багов, чем на написание нового кода
Поддерживаю. Не знаю, зачем заминусили.
Работал над маленькими и большими проектами. Работал там, где необходимо было писать тесты и там, где в этом не было потребности. Если есть возможность на фронте не писать тесты, то я только за
Это вы не видели ещё самое бестолковое) на пару недель загремел в другую команду, помочь с релизом MVP. Так у них в проекте(при том, что это MVP и надо вроде как побыстрее) буквально на каждый, даже самый мизерный компонент, написан бесполезный тест на jest, который проверяет, что компонент рендерится. Без различных комбинаций пропсов, без пограничных случаев или исключений, и все такие написанные ранее тесты перед коммитом должны пройти.
Казалось бы, ну тесты и тесты, ну запускаются там себе перед коммитом. Проблемы начались тогда, когда компонент-заглушка(на который, разумеется, написан свой тест) перестал быть таковым - в нём появился хук из RTK, а именно useAppSelector: это сломало тесты, ведь jest не знает, что это за метод, какие значения он отдаст в компонент. Теперь необходимо идти в поломанный бесполезный тест и мокать в нём хук, а так же значения, которые он вернёт для теста.
И так в каждом бесполезном тесте компонента, где ранее не использовался useAppSelector, но вдруг стал. По итогу получается какая-то обезьянья работа: тратить время на починку того, что не несёт в себе никакой пользы. Причём в будущем проект будет покрываться интеграционными тестами, что лишает написание обсуждаемых выше юнит-тестов на jest какого-либо смысла. Но тем не менее, единственным фронтенд-разработчиком на этом проекте(если не считать тех, кого время от времени присылают на помощь, как меня) тесты упорно пишутся
Тесты можно писать и редачить через ИИ. Тесты полезны тем, что показывают, что что-то где-то отвалилось или отвалится, когда настанет какой-то edge case. Писать чего-то посложнее статичного одностраничника без тестов - это приговаривать компанию тратить х часов или дней на неуловимого бага. Уж нет, спасибо, проходили через такой гемор. Писать сложное без тестов, это как заниматься в постеле без защиты - по идее можно, но даже натренированная реакция не защитит от появления детей.
Если продолжить мысль в таком же духе - можно не писать длинные осмысленные имена переменных, а обойтись лишь буквами, везде заложить any вместо соответствующего типа. И когда проект разрастётся уже думать как все это мигрировать на новые версии или вообще на другой фреймворк. Но я согласен с тем, что избыточное, излишнее тестирование это плохо и не нужно.
Да нет, почему же. Это плохо и не нужно. Но есть нюанс: обратная сторона медали (отсутствие тестов воовсе) - совсем кошмар. Так что лучше пусть будет плохо и не нужно, но есть шанс что среди ненужного - будет нужность😅
Имена переменным цикла типа "iterator" вместо "i" дают люди, написавшие мало циклов за свою жизнь (это если в частности).
Если формулировать общее правило - имена переменных должны быть тем длиннее, чем больше время их жизни (т.е. больше и разнообразнее контекст, в котором они встречаются).
Так-то в условном Хаскеле : f, a, m, k - все прекрасно понимают что значит и никто не жалуется.
Фронтендеры, хватит покрывать тестами каждую строчку кода – это безумие