Какие еще преимущества у юнит-тестов, кроме того, что они отлично обеспечивают регрессионное тестирование?

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

Собственно, есть ли у юнит-тестов еще какие-то преимущества, кроме описанных?

Недостатки:
- писать юнит-тесты более трудоемко и долго, чем тестировать вручную.
- эффективность поиска багов? опять нет. Невысока она у них. В этом их частенько обходит функциональное тестирование вручную. А тщательное прочитывание кода (тот же code review, но супер-тщательный) - вообще выигрывает у них с сухим счетом.
- изучению проекта новым членом команды (сначала он пишет тесты, потом коммитит в проект) это тоже способствует меньше, чем та же связка "функциональное тестирование + прочитка".
- и есть другие нюансы, вплоть до того, что они будут весить в "unpacked library" на npmjs.com

ИМХО, юнит-тестами, да и UI-тестами, надо покрывать далеко не всё.
  • Вопрос задан
  • 353 просмотра
Решения вопроса 7
Писать тесты может джун, это правда. Понимать что и как тестировать — это бывает и для опытного человека сложно.

Описанные недостатки — очень спорные. Метод пристального взгляда находит баги только в первые 10 минут, пока голова свежая.

Но да, с тем, что автотестами нужно покрывать не всё, я лично полностью согласен. Вдобавок, часто высокоуровневые функциональные или end-to-end тесты писать проще, а для проекта они полезнее. Тут надо искать баланс для себя. И еще в это уравнение добавить ручное тестирование. Какой-то общей формулы, понятно, нет.

А вопрос-то ваш в чём? Пока выглядит как «вы тут меня поуговаривайте писать тесты, а я вам буду объяснять, почему не буду этого делать». Не хотите — не пишите. Если для вашего проекта и для вашей команды тесты не несут большой пользы, то и не пишите их.
Судя по вашим прошлым вопросам, вы считаете, что всё знаете лучше других, соответственно, вопрос нужен, чтобы потешить ЧСВ? Ну или вы нарвались на какой-то карго-культ-секты-стопроцентного-кавереджа? В таком случае — сочувствую.
Ответ написан
saboteur_kiev
@saboteur_kiev
software engineer
Представьте себе, что есть большой проект, десятки или сотни компонентов. Несколько десятков разработчиков. При всем желании, в проекте 10% текучка означает, что часто приходит человек и ковыряет компонент, про который уже мало кто помнит. А надо быстро. А в компоненте объекты с десятком методов.

Что-то поковырял, что-то изменил, но как все в целом работает - ты понятия не имеешь.
А тут бах - и хорошие юнит тесты. Уже по ним можно понять что работает, а можно и не понимать а просто запустить и делать следующую задачу.
Ответ написан
@jazzus
500 ошибки это слишком просто, они в логах. Гораздо сложнее и грустнее обнаружить логическую ошибку, которая висела месяцами и никто не знал. Плюс, если ты уже код научился писать и юзаешь IDE, то все 500 ошибки будут в дев режиме. Тесты нужны, в первую очередь, для фиксации функционала и тз. Я пишу только http тесты и до разработки. Чтобы руками формы по 100 раз не забивать. А то я тут одно видео видел, где ларавельщик регистрацию проверял и с каждым изменением форму заново заполнял и отправлял. По мне так низкокачественная, скучная и неэффективная разработка. С тестами все проверки автоматом, просто разрабатываешь до зелени. И потом уверенно заливаешь на продакшн и знаешь, что все работает, как задумано, а не как получилось.
Ответ написан
dimonchik2013
@dimonchik2013
non progredi est regredi
тесты должны проверять что

а) прилжение работает так как нужно с правильными данными
и
б) приложение не работает как не нужно с неправильными данными, или не работает вообще

с тестами всего одна проблема, неумение следовать пункту (б), и тут джун вряд ли справится
но у кого п (б) учтен, экономят много (не хочу писать "сотни", проекты разные) человекочасов
Ответ написан
vabka
@vabka
Токсичный шарпист
отлично обеспечивают регрессионное тестирование?

Юниты кстати не всегда могут это обеспечить.
Вполне обычная ситуация - все функции и классы работают идеально, но в приложении всё ломается, тк кто-то криво зарегал их в ioc, или опечатался в имени

- писать юнит-тесты более трудоемко и долго, чем тестировать вручную.

нет. Если имеется нормальный фреймворк для тестирования, то написать всю тестовую документацию и протестировать руками будет дольше, чем написать e2e тесты.

ИМХО, юнит-тестами, да и UI-тестами, надо покрывать далеко не всё.

Да
Ответ написан
@vitaly_il1
DevOps Consulting
Понятно, что юнит тесты не защитят от всего, но все-таки помогают.
Кстати, посмотрите на https://ru.wikipedia.org/wiki/%D0%9C%D1%83%D1%82%D... - очень интересный метод который помогает улучшить качество тестирования.
Ответ написан
Комментировать
DevMan
@DevMan
давай ты проработаешь хоть пяток лет. а потом еще столько же, но на руководящих должностях.
и вот только потом будешь задавать подобные этому (и другим своим) вопросы.
сейчас ты просто не поймешь ответы.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы