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

 Ну, и еще одно негласное преимущество: они являются "как-бы-частью-продукта". И их наличие с точки зрения многих заказчиков "как-бы-плюс". Всем мозги промыли :)  

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

И заказчики рады, да.  

До тех пор, пока не посыплются баги. А они - посыплются. И вот об этом - дальше.  

  

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

  

Недостатки:  

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

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

- изучению проекта новым членом команды (сначала он пишет тесты, потом коммитит в проект) это тоже способствует меньше, чем та же связка "функциональное тестирование + прочитка".  

- и есть другие нюансы, вплоть до того, что они будут весить в "unpacked library" на npmjs.com  

  

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

*Писать* тесты может джун, это правда. *Понимать что и как тестировать* — это бывает и для опытного человека сложно.  

  

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

  

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

  

А вопрос-то ваш в чём? Пока выглядит как «вы тут меня поуговаривайте писать тесты, а я вам буду объяснять, почему не буду этого делать». Не хотите — не пишите. Если для вашего проекта и для вашей команды тесты не несут большой пользы, то и не пишите их.  

Судя по вашим прошлым вопросам, вы считаете, что всё знаете лучше других, соответственно, вопрос нужен, чтобы потешить ЧСВ? Ну или вы нарвались на какой-то карго-культ-секты-стопроцентного-кавереджа? В таком случае — сочувствую. 

 Представьте себе, что есть большой проект, десятки или сотни компонентов. Несколько десятков разработчиков. При всем желании, в проекте 10% текучка означает, что часто приходит человек и ковыряет компонент, про который уже мало кто помнит. А надо быстро. А в компоненте объекты с десятком методов.  

  

Что-то поковырял, что-то изменил, но как все в целом работает - ты понятия не имеешь.  

А тут бах - и хорошие юнит тесты. Уже по ним можно понять что работает, а можно и не понимать а просто запустить и делать следующую задачу. 

 500 ошибки это слишком просто, они в логах. Гораздо сложнее и грустнее обнаружить логическую ошибку, которая висела месяцами и никто не знал. Плюс, если ты уже код научился писать и юзаешь IDE, то все 500 ошибки будут в дев режиме. Тесты нужны, в первую очередь, для фиксации функционала и тз. Я пишу только [http тесты](https://laravel.com/docs/8.x/http-tests) и до разработки. Чтобы руками формы по 100 раз не забивать. А то я тут одно видео видел, где ларавельщик регистрацию проверял и с каждым изменением форму заново заполнял и отправлял. По мне так низкокачественная, скучная и неэффективная разработка. С тестами все проверки автоматом, просто разрабатываешь до зелени. И потом уверенно заливаешь на продакшн и знаешь, что все работает, как задумано, а не как получилось. 

 тесты должны проверять что  

  

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

и  

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

  

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

но у кого п (б) учтен, экономят много (не хочу писать "сотни", проекты разные) человекочасов 

> отлично обеспечивают регрессионное тестирование?

  

Юниты кстати не всегда могут это обеспечить.  

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

  

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

  

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

  

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

  

Да 

 Понятно, что юнит тесты не защитят от всего, но все-таки помогают.  

Кстати, посмотрите на [https://ru.wikipedia.org/wiki/%D0%9C%D1%83%D1%82%D...](https://ru.wikipedia.org/wiki/%D0%9C%D1%83%D1%82%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B5_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5) - очень интересный метод который помогает улучшить качество тестирования. 

 давай ты проработаешь хоть пяток лет. а потом еще столько же, но на руководящих должностях.  

и вот только потом будешь задавать подобные этому (и другим своим) вопросы.  

сейчас ты просто не поймешь ответы.