Какие еще преимущества у юнит-тестов, кроме того, что они отлично обеспечивают регрессионное тестирование?
Ну, и еще одно негласное преимущество: они являются "как-бы-частью-продукта". И их наличие с точки зрения многих заказчиков "как-бы-плюс". Всем мозги промыли :)
При этом писать их может даже очень зеленый джун. Не нужно вводить его в курс проекта, просто скажите ему научиться писать тесты, помогите минимально разобраться с вашим тестовым окружением (настолько, насколько оно вообще есть как таковое) и он будет их писать. Типа человек при деле.
И заказчики рады, да.
До тех пор, пока не посыплются баги. А они - посыплются. И вот об этом - дальше.
Собственно, есть ли у юнит-тестов еще какие-то преимущества, кроме описанных?
Недостатки:
- писать юнит-тесты более трудоемко и долго, чем тестировать вручную.
- эффективность поиска багов? опять нет. Невысока она у них. В этом их частенько обходит функциональное тестирование вручную. А тщательное прочитывание кода (тот же code review, но супер-тщательный) - вообще выигрывает у них с сухим счетом.
- изучению проекта новым членом команды (сначала он пишет тесты, потом коммитит в проект) это тоже способствует меньше, чем та же связка "функциональное тестирование + прочитка".
- и есть другие нюансы, вплоть до того, что они будут весить в "unpacked library" на npmjs.com
ИМХО, юнит-тестами, да и UI-тестами, надо покрывать далеко не всё.
Алексей Уколов, я предвидел, что будет с этим путаница. Но ведь реально, автоматические тесты - это либо юнит-. либо UI-.
И да, в вопросе имеются в виду автоматические юнит-тесты. Ручные юнит-тесты - не возбраняются, но в большом количестве неэффективны, лучше ручные функциональные тесты
Алексей Уколов, это когда ты берешь и вручную тестируешь какой-то модуль, по возможности отдельно от остальных. Например, сначала ты дернул некий метод сервера, самостоятельно сформировав нужный запрос, потом сделал это с помощью клиентской библиотеки - обертки, потом другой клиентской библиотеки. Тестируется в этом случае сначала обработчик метода сервера, потом обертка из одной библиотеки, потом из другой.
А ручной функциональный тест - это если бы сразу дернул метод из одной библиотеки и из другой, при этом вроде бы ты тестируешь систему в целом, но ты не можешь протестировать, что будет, если юзверь напишет свой клиент-велосипед без этих библиотек и отправит нечто неподобающее, такое, что библиотеки бы никогда не отправили.
Но ведь реально, автоматические тесты - это либо юнит-. либо UI-.
А куда потерялось функциональное тестирование? Я имею ввиду тестирование не на уровне юнитов, а на уровне системы в целом, интеграционное тестирование?
Писать тесты может джун, это правда. Понимать что и как тестировать — это бывает и для опытного человека сложно.
Описанные недостатки — очень спорные. Метод пристального взгляда находит баги только в первые 10 минут, пока голова свежая.
Но да, с тем, что автотестами нужно покрывать не всё, я лично полностью согласен. Вдобавок, часто высокоуровневые функциональные или end-to-end тесты писать проще, а для проекта они полезнее. Тут надо искать баланс для себя. И еще в это уравнение добавить ручное тестирование. Какой-то общей формулы, понятно, нет.
А вопрос-то ваш в чём? Пока выглядит как «вы тут меня поуговаривайте писать тесты, а я вам буду объяснять, почему не буду этого делать». Не хотите — не пишите. Если для вашего проекта и для вашей команды тесты не несут большой пользы, то и не пишите их.
Судя по вашим прошлым вопросам, вы считаете, что всё знаете лучше других, соответственно, вопрос нужен, чтобы потешить ЧСВ? Ну или вы нарвались на какой-то карго-культ-секты-стопроцентного-кавереджа? В таком случае — сочувствую.
Писать тесты может джун, это правда. Понимать что и как тестировать — это бывает и для опытного человека сложно.
Но писать их все равно будет джун. И немножко - автор функционала, который и надо тестировать. На практике даже миддл уже пишет их очень лениво и только на свою часть функционала.
А это так потому, что в команде нет лишних людей, и кропотливую работу делать никто не хочет. А еще считают эту работу менее квалифицированной, так что если какой-то миддл+ захочет делать тесты вместо своих задач, то это будет минус в карму. А еще есть джун, который напишет тесты хотя бы на уровне той самой "части-продукта", и таки напишет ведь!, даже если другие части продукта он ни в жизнь не сделал бы нормально.
Метод пристального взгляда находит баги только в первые 10 минут, пока голова свежая.
Почему же? Если голова не свежая, ты можешь просто дольше читать код. Многие баги делаются по невнимательности и легко выявляются осмыслением каждой буковки в коде.
Ну или вы нарвались на какой-то карго-культ-секты-стопроцентного-кавереджа, в таком случае — сочувствую.
Примерно так. Меня не спрашивают, хочу я тесты или нет.
Но писать их все равно будет джун. И немножко - автор функционала, который и надо тестировать. На практике даже миддл уже пишет их очень лениво и только на свою часть функционала.
Не везде.
А еще считают эту работу менее квалифицированной, так что если какой-то миддл+ захочет делать тесты вместо своих задач, то это будет минус в карму. А еще есть джун, который напишет тесты хотя бы на уровне той самой "части-продукта", и таки напишет ведь!, даже если другие части продукта он ни в жизнь не сделал бы нормально.
Не везде.
Почему же? Если голова не свежая, ты можешь просто дольше читать код. Многие баги делаются по невнимательности и легко выявляются осмыслением каждой буковки в коде.
Головы бывают разные и работают они тоже по-разному.
Примерно так. Меня не спрашивают, хочу я тесты или нет.
Увольняйтесь и идите туда, где будут разделять вашу точку зрения. Или терпите.
А где-то тесты пишет лид? Где это такое? И в этом тоже свои минусы - он может ошибку найти и выговор сделать. А вот джун... он может в явную об этом сказать в присутствии того же лида, а может и нет, тут уж смотря какие отношения с джуном у тебя :)
Головы бывают разные и работают они тоже по-разному.
Если голова настолько тупая, что после 10 минут активной работы не то что медленно соображает, а вообще не соображает, то увольняйтесь.
Если голова настолько тупая, что после 10 минут активной работы не то что медленно соображает, а вообще не соображает, то увольняйтесь.
Ещё головой орехи колоть тяжело. Тоже увольняться, или можно использовать для этого специально придуманный инструмент? Ну, знаете, как в случае с тестами?
Ещё раз - если вы попали в команду, с которой у вас расходятся подходы к разработке, вам можно только посочувствовать, но данный ресурс не для этого создавался.
ни у кого не было проектов где от автотестов отказывались потому что их поддержка начинала занимать слишком много времени? и они начинали понемногу покрываться закомментаренными кусками кода?
Dmtm, были, конечно. Поэтому тут автору никто и не говорит "пиши тесты на всё и молчи в тряпочку". Поиск баланса, когда тесты приносят больше пользы, чем вреда - тонкое искусство, требующее опыта. И обычно это качели - сначала разработчик ничего не пишет, потом пишет тесты на всё, потом находит адекватное для своих условий соотношение.
Если тесты не пишет автор кода, то вали оттуда, да поскорее.
Пишет. Но очень мало кейсов покрывает. Так что пишет тесты способные выявить слишком мало ошибок. В частности, допущенных по невнимательности.
Потом эти тесты дописывает другой человек (обычно джун).
Но все равно не существует тестов, способных выявить все ошибки, не существует вообще. Да, ручное тестирование тоже выявляет не все ошибки. Оно не выявит какое-нибудь переполнение типа, ты не будешь все параметры числовых типов тестить на переполнение типа, а все строки тестить на потребление ОЗУ и быстродействие при таких больших строках.
К "выявить все ошибки" близко лишь вычитывание кода.
Ещё головой орехи колоть тяжело. Тоже увольняться, или можно использовать для этого специально придуманный инструмент? Ну, знаете, как в случае с тестами?
Если бы орехи были багами, а ничем кроме головы не кололись на 99-100%, то да, нужно было бы увольняться.
А баги действительно не колются никакими юнит-тестами на 99-100%. И ручными-то тестами тоже не колются.
Ты не будешь все параметры числовых типов тестить на переполнение типа, все строки тестить на потребление ОЗУ и быстродействие при таких больших строках, во все объекты (если это JS и т.п. ) добавлять опять же кучу свойств и тестить (вдруг там копирование и это чудовищно медленно)... Ты не будешь тестить правильность всех exception'ов и их message'й и удобство отлова этих экскепшнов при вызове этого кода...
Или будешь? Ну, тогда ты точно не будешь вызывать код с random тысячи раз - вдруг он фейлится на малых и больших значениях этого рандома...
К этим 99-100% максимально близок лишь "метод пристального взгляда".
Представьте себе, что есть большой проект, десятки или сотни компонентов. Несколько десятков разработчиков. При всем желании, в проекте 10% текучка означает, что часто приходит человек и ковыряет компонент, про который уже мало кто помнит. А надо быстро. А в компоненте объекты с десятком методов.
Что-то поковырял, что-то изменил, но как все в целом работает - ты понятия не имеешь.
А тут бах - и хорошие юнит тесты. Уже по ним можно понять что работает, а можно и не понимать а просто запустить и делать следующую задачу.
приходит человек и ковыряет компонент, про который уже мало кто помнит
Так надо вспомнить. С таким же успехом можно жаловаться на то, что вообще существуют большие проекты, в которых всего не упомнить. Ну просто ни в какие ворота же! Даешь перфокарты, а лучше деревянные счеты.
Saboteur, 3 года самый длинный и был, но из них только последние 1.5 года не писались юнит-тесты вообще. А как думаешь, в какой из этих периодов багов больше было - когда юнит-тесты писались, но код никто не вычитывал, или когда я код вычитывал, а юнит-тесты не писались?
У меня был вопрос "от трех лет", а у тебя самый длинный был 3...
Я думаю, что багов больше было там, где к работе относились наплевательски.
Если вычитывать и код и юнит тесты, то будет работать и то и другое.
Если делать что-нибудь просто на "от...тесь", то работать будет плохо. Как бы и ежу понятно.
Saboteur, видишь ли, чтобы написать юнит-тест не на "от...тесь", нужно фактически вычитать весь код, и вдобавок собственно написать юнит-тест.
То есть это ещё тяжелее и дольше, чем просто вычитать весь код. А ведь и просто вычитать весь код - это тоже отнюдь не просто. Это сложно, это тяжело.
Именно поэтому все юнит-тесты на самом деле пишутся на "от...тесь". И на самом деле они обладают гораздо меньшим покрытием кода, чем заявляют разработчики. Достаточно взять любой модуль, тестируемый ими, и попытаться испортить его так, чтобы баг был, но тесты не сломались. Самый простой, очевидный, смешной вариант - это воткнуть туда что-то типа: if (random() == magic_number) crash();
Это, конечно, уже стеб, но в каждом стебе есть доля смысла. В данном случае это иллюстрация полной неэффективности тестов против багов типа "черный лебедь", например переполнений числовых типов, которые возникают лишь на больших значениях. И далеко не всегда это большие значения входных параметров модуля. Если там какие-то сложные расчеты, то х... ты покроешь это тестом, даже если поставишь цель - протестить вот здесь переполнение. А таких "здесь", с возможными переполнениями, может быть в каждом втором модуле, если не в каждом первом...
Ну, и еще одни момент: ты не совсем прав, когда говоришь, что если делать на "от...тесь", то будут баги. На самом деле баги еще характерны для, наоборот, очень трудолюбивых и увлеченных людей. У них от переутомления падает внимательность, а это верный способ наплодить самых жутких "черных лебедей", как и другие ошибки. И вот это уже никак не решить, кроме вычитывания и вообще перепроверки всего и вся.
видишь ли, чтобы написать юнит-тест не на "от...тесь", нужно фактически вычитать весь код, и вдобавок собственно написать юнит-тест.
То есть это ещё тяжелее и дольше, чем просто вычитать весь код. А ведь и просто вычитать весь код - это тоже отнюдь не просто. Это сложно, это тяжело.
Нет, потому что юнит-тест обычно пишется тогда, когда ты пишешь этот весь код. Если с момента создания класса, к нему сразу есть юнит тест, это означает что больше этот код целиком вычитывать не нужно.
А учитывая, что проект может жить долго, это означает что никому из разработчиков не нужно будет вычитывать весь код, только подправлять нужный кусок, и подправлять нужный кусок юнит-теста.
Проблема заключается в том, что ты либо не работал в проектах, где юнит-тесты писали сразу и они просто работали, либо у тебя большинство проектов были написаны тобой в одиночку или в очень маленькой команде (3-5 разработчиков), а в проектах, над которым работает несколько десятков людей ты не работал.
Поэтому ты смотришь на ситуацию исключительно со своей точки зрения, где ты ВСЕ хочешь делать вручную.
На самом деле баги еще характерны для, наоборот, очень трудолюбивых и увлеченных людей. У них от переутомления падает внимательность, а это верный способ наплодить самых жутких "черных лебедей", как и другие ошибки. И вот это уже никак не решить, кроме вычитывания и вообще перепроверки всего и вся.
ИМЕННО от этого и выручает автоматическое тестирование, первый шаг в котором это юнит тесты.
Если с момента создания класса, к нему сразу есть юнит тест, это означает что больше этот код целиком вычитывать не нужно.
Глупость. Вот ты создал класс, и допустил в нем ошибку по невнимательности. Вот ты написал юнит-тест, прогнал его. А он, допустим, НЕ выявил эту ошибку, потому что она "черный лебедь". И вот ты имеешь код с ошибкой и юнит-тест к нему, который не находит эту ошибку.
И найти ее теперь можно, только вычитав код.
Есть и еще более прикольный вариант: это когда допускаешь ошибку не столько реализации кода, сколько самого проектирования алгоритма. И спокойненько пишешь тест... который проверяет работу реализации алгоритма... а реализация-то правильная.
В этом случае, возможно, ошибку удастся найти и без вычитывания, просто надо вернуться к этому коду спустя время и посмотреть на него с другой стороны А еще лучше - попросить коллегу сделать это. Но так или иначе, это тоже пример случая, где тест, написанный сразу вместе с кодом, не только не помогает обнаружить баг, но и мешает.
или в очень маленькой команде (3-5 разработчиков), а в проектах, над которым работает несколько десятков людей ты не работал.
Да, в очень маленькой команде. И юнит-тесты там, конечно, писали. И баги в коде, на который их писали, тоже были. И именно по сценариям, что я описал выше.
А что, если бы были десятки человек, то что-то поменялось бы? И кстати, а много ли ты видел проектов, где нету багов?
ИМЕННО от этого и выручает автоматическое тестирование, первый шаг в котором это юнит тесты.
Это ты зачем написал? Чтобы я повторил для тебя, как для прапорщика? Ок.
Повторяю: нет, оно от этого не спасает. Я же тебе написал, почему оно не спасает. Потому что баг типа "черный лебедь" требует множества условий, чтобы проявиться. При автотестах невозможно создать такое, не зная заранее, что в коде есть баг. И при ручных тестах не создать. Только вычитыванием можно такой баг найти.
А еще раз повторить?
А что, если бы были десятки человек, то что-то поменялось бы? И кстати, а много ли ты видел проектов, где нету багов?
Поменялось бы то, что приходят новые люди, которые еще этот код весь не вычитывали, и КАЖДОМУ надо вычитать. А представь, что в проекте компонентов сотни. Десятки человек должны каждый раз вычитывать сотни компонентов до конца?
Я рекомендую тебе осознать простую вещь.
Есть инструмент. Юнит тесты.
Его удобно использовать в определенных ситуациях.
Если лично тебе не удобно - никто тебя не заставляет.
Но вот утверждать, что юнит тесты - всегда бесполезны - это в тебе говорит недостаток опыта и юношеский максимализм.
500 ошибки это слишком просто, они в логах. Гораздо сложнее и грустнее обнаружить логическую ошибку, которая висела месяцами и никто не знал. Плюс, если ты уже код научился писать и юзаешь IDE, то все 500 ошибки будут в дев режиме. Тесты нужны, в первую очередь, для фиксации функционала и тз. Я пишу только http тесты и до разработки. Чтобы руками формы по 100 раз не забивать. А то я тут одно видео видел, где ларавельщик регистрацию проверял и с каждым изменением форму заново заполнял и отправлял. По мне так низкокачественная, скучная и неэффективная разработка. С тестами все проверки автоматом, просто разрабатываешь до зелени. И потом уверенно заливаешь на продакшн и знаешь, что все работает, как задумано, а не как получилось.
Василий Банников, ты с сарказмом или как? Мне тоже немного странным показалось, почему функциональные тесты на какой-то сервер\сервис называют HTTP-тестами. Хотя, если придерживаться жОсткого REST по всем канонам... Но тогда это можно назвать и REST-тестами)
beem7, без сарказма. Это хороший подход.
Ещё такой вариант идеально подходит, если уже есть некоторое апи без тестов вообще, и хочется быстро сделать хорошее покрытие, чтобы нормально рефакторить
Василий Банников, мне кажется странным само название. HTTP? А если там ws добавят как новый транспорт? Мне кажется, хорошую вещь так тупо называть не будут.
beem7, название 100% соответствует способу тестирования. Если открыть ссылку, то кроме теста http запросов и ответов ничего нет. Например, для консольных, бд и др. тестов есть свои разделы. Ларавел - это фреймворк с огромным сообществом. И если тебе что-то кажется странным и плохим, возможно стоит задуматься - "а не ошибаюсь ли я". И попробовать разобраться в вопросе. Понятно, найдется множестве причин этого не делать. Во-первых лень. Во вторых понятно, что они там все дураки, а я умный. Но зернышко такой мысли посеять не помешает)
а) прилжение работает так как нужно с правильными данными
и
б) приложение не работает как не нужно с неправильными данными, или не работает вообще
с тестами всего одна проблема, неумение следовать пункту (б), и тут джун вряд ли справится
но у кого п (б) учтен, экономят много (не хочу писать "сотни", проекты разные) человекочасов
Юниты кстати не всегда могут это обеспечить.
Вполне обычная ситуация - все функции и классы работают идеально, но в приложении всё ломается, тк кто-то криво зарегал их в ioc, или опечатался в имени
- писать юнит-тесты более трудоемко и долго, чем тестировать вручную.
нет. Если имеется нормальный фреймворк для тестирования, то написать всю тестовую документацию и протестировать руками будет дольше, чем написать e2e тесты.
ИМХО, юнит-тестами, да и UI-тестами, надо покрывать далеко не всё.
нет. Если имеется нормальный фреймворк для тестирования, то написать всю тестовую документацию и протестировать руками будет дольше, чем написать e2e тесты.
А если не писать ничего вообще, а просто тестировать руками, то будет быстрее.
В этом случае дольше может быть только если не настроено окружение для тестирования руками, а для выполнения юнит-тестов - настроено. Ну так настрой его.
А если не писать ничего вообще, а просто тестировать руками, то будет быстрее
Удачи делать регресс всего проекта.
e2e тестами это будет минут 30
Юнитами - меньше минуты (но проблему "все тесты зелёные, а нифига не работает" я уже упомянул)
Руками - дофига.
Юниты тесты - это больше инструмент разработки, а не обеспечения качества (имхо)
Моя точка зрения - если что-то повтораяется уже третий раз, и при этом это можно автоматизировать - надо автоматизировать.
Понятно, что юнит тесты не защитят от всего, но все-таки помогают.
Кстати, посмотрите на https://ru.wikipedia.org/wiki/%D0%9C%D1%83%D1%82%D... - очень интересный метод который помогает улучшить качество тестирования.
давай ты проработаешь хоть пяток лет. а потом еще столько же, но на руководящих должностях.
и вот только потом будешь задавать подобные этому (и другим своим) вопросы.
сейчас ты просто не поймешь ответы.
Алексей Уколов, в том, что тупо такое применение джунам находить, что и отметил в вопросе. Если в проекте а) зеленые джуны б) надо найти им применение, да еще чтобы создавали какую-то "часть-продукта", то проект - плохой, денег в нем - мало, и надо это понимать.
Простой
Простой
Простой
Простой
Простой
Простой
