Как стать автором
Обновить

Комментарии 7

Не знаю, я вообще не сторонник модульных тестов. Сколько с ними не сталкивался, всегда поддержание тестового колхоза со всеми его моками и прочим непотребством занимало время, сравнимое с разработкой, при этом подавляющее большинство тестов отвечали на один, совершенно второстепенный вопрос: "соблюдает ли модуль свой контракт" (и это естественно, это и есть назначение модульных тестов). А вот реальные ошибки и проблемы, они практически всегда вылезали на межмодульном взаимодействии, и соответственно, ловили их успешно только интеграционные тесты. Поэтому я люблю интеграционные тесты, и не люблю модульные :)

Так я хочу и на ёлку влезть и попу не ободрать. Пусть тесты пишут генераторы и роботы, они железные. А я весь в белом сочиняю BDD, которые не только для тестов полезны, но и как документация в актуальном состоянии, и как декомпозированные таски etc.

Уже не раз тесты спасали во время большого рефакторинга системы.

При изучении математики в школе вы, вероятно, узнали о факторизации. 

А в ПТУ вы узнаете слово factory и это перевернёт ваше представление о мире.

Модульные тесты направлены против "модулей", как я описал. Они никогда не были направлены только против одного класса/функции/чего-либо еще.

Но ведь модуль - это буквально и есть файл/класс/функция/что-либо ещё.

  • Проверьте, что тест не работает с явной ошибкой (красный цвет)

А если он сразу зелёный - что делать?

В наше время этого легко добиться с помощью ChatGPT. 

А вы сами его пробовали? Он такую чушь пишет..

Prompt Engineering - отдельный скилл. Я с ними (ChatGPT / Codeium) постоянно разговариваю, и часто с кривой ухмылкой. Но правильно заданный вопрос - половина решения. Конкретно тут, если вводные строго определены (сигнатура функции и код без сайд-эффектов), то результат вполне годный.

Никуда он не годный. Половина кейсов тестируют одно и то же. А другой половины попросту нет. И пока сформулируешь правильный запрос, чтобы выдавить из этого студента правильный ответ, уже 10 раз сам правильный код напишешь.

Юнит тесты нужны, только они очень дорогие (кто бы что не говорил). У меня затраты по времени на них получаются почти всегда больше чем на сам код. Но они реально помогают найти ошибки во всяких краевых случаях, а иногда и сходу. Тесты нужно писать самому исходя из своих ожиданий от того как должна работать программа (а не тупо чтобы получить покрытие). А чтобы не было больно при рефакторинге - ну надо писать тесты только на публичные методы, а не на детали реализации, хоть и есть такой соблазн иногда

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории