Как стать автором
Поиск
Написать публикацию
Обновить

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

"Совет: Начинайте писать тесты сразу, как только создали метод. Это проще, чем исправлять баги потом!"

Совет из TDD: Начинайте писать тест ДО того как создали метод, убеждаемся что тест не проходит и только потом создаём метод который проходит тест, рефакторим, убеждаемся что проходит, думаем а какой функционал ещё нужен? добавляем новый тест, убеждаемся что он не проходит, меняем или добавляем новый метод, чтобы он его проходил, рефакторим и смотрим чтобы уже два теста проходили, и так накручиваем

Такой способ даёт 100% покрытие и 100% предсказуемость, а так же крепкий сон, исключает драмы в стиле почему когда я парсил json у меня дропнулась таблица в бд

если ты не знаешь чего тестировать - скорее всего либо тебе не ясна задача, либо тебе дали задание в стиле "сделай как нибудь" , значит и делай как нибудь, но я так не делаю, потому что потом всё будешь переписывать, руководствуюсь другим принципом - стараюсь делать хорошо, хренова всегда получится, когда ты пишешь тест ты четко понимаешь что ты хочешь на выходе при таком входе, а значит и проще объяснить железяке, поэтому относиться ко времени на тесты нужно как на проектирование, а не само программирование

Добавлять зависимости junit 5.xx явно не всегда нужно. Нередко они включены в уже подключенные ранее зависимости (например spring boot starter). А вот без Maven Surefire plugin проект с тестами реально может не собраться.

Так же, стоит добавить, что зависимость spring boot test поставляет базовые библы для интеграционного тестирования.

PS: от тестов еще никому плохо не было. Плюсов - масса. Но бизнес не всегда готов их оплачивать и иногда нужно убеждать бизнес закладывать время и деньги на юнит, интеграционное и контейнерное тестирование. А это может добавлять до 30-40% объема кода и времени. Но, все же, старайтесь убедить бизнес в необходимости тестирования на стадии написания кодовой базы, даже если он хочет от этого отказвться. Это потом сэкономит и нервы и время и деньги всем.

Не совсем понятно из заголовка, зачем новичкам эти советы, если новички и так по 100 часов экономят?

Если по делу. В статье намешаны понятия, которые казалось бы про одно, но при этом про разное. Тестировщики пишут автоматизированные функциональные тесты, которые ещё и проверяют, что система корректно работает после установки на полноценный стенд близкий к проду. А unit-тесты пишутся разработчиками, и проверяют каждый отдельный метод/функцию, и могут даже проверять, что обращение к репозитори не происходит больше одного раза.

Где вы видели, чтобы джун писал на проекте unit тесты?

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