Одержимость покрытием юнит-тестами

Тут есть тонкий момент - хорошие тесты, дают хорошее покрытие, точно не ниже пресловутых 75%. Но вот хорошее покрытие не есть признак хороших тестов нм разу. Объяснить это людям сверху обычно довольно сложно, но можно. А именно надо заговорить про увеличение костов, сразу после вводной, сказки про 20/80, и предложения сосредоточиться на метркиках а не на качестве.

Я буквально могу перечислить по пальцам одной руки случаи, когда тесты краснели из-за пойманных ошибок. В 99% случаев это происходит потому, что в процессе изменений продуктового кода меняются интерфейсы юнитов (сигнатуры методов). И тесты приходится поддерживать, поддерживать и поддерживать. Чтобы если повезет, когда-нибудь увидеть действительно полезный не прошедший тест.

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

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

Я 10 лет пишу на жабе, предпочитаю интеграционные тесты, они и тестят публичные интерфейсы, а не внутренние и промежуточные представления и стояния, потому не то что не не мешают, а наоборот, помогают все переделывать, т.к. интерфейс того же REST API не меняется, а все внутренности можно переписать полностью, интеграционный тест лишь подтвердит что контракты не поломались.

Ну слишком маленький размер юнита может создать некоторый геморрой. Возможно имеет смысл делать тесты уровнем выше.

Все еще от проекта зависит. В крудах модульные тесты менее актуальны чем при всякой накрученной бизнесовой логике.

У такого подхода есть и обратая цена, сложно понять почему оно упало. Вот есть у тебя интеграционный тест, в котором стоит утверждение на price == 25.45 и поди найди почему она изменилась где-то там глубоко в кишках всей этой замоканой лапши.

в кишках всей этой замоканой лапши.

Интеграционным тестам моки не нужны.

Нет большой разницы, когда пишутся тесты: до или после. В контексте твоего вопроса уж точно.

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

Во-первых, представь, что у тебя есть «вспомогательная» функция А и «главная» Б. Ты тестируешь Б и вроде все ок. Но у А могут быть свои краевые случаи, которые недостижимы из Б. Таким образом, когда ты начнешь использовать А из другого места или из той же Б, но чуть иначе, могут вылезти неоттестированные места.

Во-вторых, тесты — это пресловутая культура разработки, и это не пустые слова. Когда ты пишешь тесты, ты как правило лучше обдумываешь краевые случаи. Их всегда много, и о них иногда забываешь в процессе написания кода. Кроме того, тесты могут выступать входной точкой при изучении кода. Зачастую проще понять логику класса или функции через чтение их тестов.

Да, моки тут явно не в тему, но основная мысль чертовски верна. Когда падает интеграционный или функциональный тест, бывает чертовски трудно понять, из-за чего. Во всякой распределенке это вообще капец.

Ну и вообще мысль «тесты почти никогда не падают из-за поломки кода» вообще никак не говорит «тесты не нужны». Они не падают, потому что благодаря ним код написан хорошо.

Одержимость покрытием юнит-тестами

Пройдёт.

Без упоминания конкретной сферы по поводу тестов не о чем говорить. Для каких-нибудь изолированых обработчиков в тщательно контролируемой среде тесты работают прекрасно и даже поверхностное покрытие дает хороший результат. В GUI на пользовательских компах и в распределенке хоть с ног до головы обмажься тестами - все равно придет ламер, который ткнет неожиданную кнопку или у которого стоит стороннее кривое ПО в системе; или на рождество придет огромный наплыв посетителей с одинаковыми запросами и уронит систему.

В 99% случаев это происходит потому, что в процессе изменений продуктового кода меняются интерфейсы юнитов (сигнатуры методов). И тесты приходится поддерживать, поддерживать и поддерживать. Чтобы если повезет, когда-нибудь увидеть действительно полезный не прошедший тест

Первая и единственная цель тестов - это снижение затрат на разработку. Невозможно гарантировать общую корректность программы по выполнению на отдельном наборе входных данных и условий. Потому тесты нам нужны тогда, когда нас не волнует абсолютная корректность, а нужно просто проверить, что программа работает. Если тесты становятся преградой в упрощении разработки, то от тестов избавляются.

Складывается ощущение, что «code coverage» с развитием CI/CD стал вездесущ и очень часто от него попахивает карго-культом.

Карго культом является CI/CD, прежде всего, а покрытие тестами - это уже развитие и углубление карго культа.

но основная мысль чертовски верна.

С этим не спорю.

Есть точка зрения, что юнитом в юнит-тестировании должен быть не отдельный метод, а некая логическая единица работы, часто она будет включать в себя несколько методов и даже классов.

Есть точка зрения что это у вас, наоборот, юнитом является хрен пойми какая «логическая единица работы» вместо метода или класса выполняющего одну функцию как должнó, поэтому и интерфейсы постоянно меняются. В адекватной разработке когда соблюдается SRP и другие хорошие методологии, и есть хотя бы минимальный план развития продукта код как правило пишется один раз, покрывается тестами и нужды менять в нём API больше не возникает.

Считаю их полезными, когда юнит устойчив и содержит в себе некую ключевую логику, которую действительно имеет смысл тестировать атомарно.

Правильно. Но весь код должен быть «ключевой логикой, которую имеет смысл тестировать атомарно», а не сильносвязанной лапшой.

PS. Адептом TDD я конечно же не являюсь и дрочевом на покрытие не занимаюсь, но знаю что нормальный код можно при желании покрыть на 95% и не тратить сколь либо заметного времени на поддержку тестов при его последующем развитии.

Придерживаюсь принципа «тестировать только то, что может сломаться». Если метод из трех строчек просто получает данные и передает в другой, то его не тестирую. Ну или просто метод тривиален. Подобное почти не ломается, только лишняя работа, если что, вылезет в интеграционных тестах.

Чтобы если повезет, когда-нибудь увидеть действительно полезный не прошедший тест

Если повезёт, то ты никогда не увидишь непрошедший тест. Именно в этом и заключается польза.

Главная причина - хрупкость этих самых тестов

Код принципиально хрупок, как и любая сложная вещь с кучей взаимозависимых компонентов. У тебя есть два стула - чинить ломающиеся тесты, или чинить ломающийся прод.

закрадывается подозрение, что подобное покрытие юнит-тестами - напрасная трата времени

Зависит от того с какой колокольни смотреть. В конечном счёте решают совсем не технические причины. Т.е. тесты полезны, но не бесплатны. В т.ч. если тебе за них платят, то в чём проблема?

У тебя есть два стула - чинить ломающиеся тесты, или чинить ломающийся прод

Ну а как же стул «переработать тесты на более общие»? Грубо говоря, он избавится от 80% проблем с тестами, получив на 20% больше проблем в проде.

Зависит от того с какой колокольни смотреть. В конечном счёте решают совсем не технические причины. Т.е. тесты полезны, но не бесплатны. В т.ч. если тебе за них платят, то в чём проблема?

Без шуток - это серьезный подход к делу. Зачем что-то чинить, если и так платят?

нормальный код можно при желании покрыть на 95% и не тратить сколь либо заметного времени на поддержку тестов при его последующем развитии

Это тебе так кажется. На практике в 90% случаев программы пишутся не как инженерный проект, который сначала полностью планируется, а потом реализуется с какими-то мелкими доработками, а скорее как исследовательский, по принципу «хочу то не знаю что». Через несколько лет разработки код может быть переписан чуть ли не целиком. И тесты соответственно тоже. Не потому что не умеют планировать, а потому что это вообще невозможно, т.к. обстоятельства и требования меняются постоянно из-за различных внешних причин.

Как ни парадоксально, это результат наличия тестов :)

Объясните парадокс) Тесты пишутся после кода и в течение своего жизненного цикла ни разу не детектят ошибки (повторюсь, 99% из тех, что я видел, именно такие), но требуют поддержки.

Когда ты пишешь тесты, ты как правило лучше обдумываешь краевые случаи. Их всегда много, и о них иногда забываешь в процессе написания кода.

Такое бывает, да. Но я бы не сказал, что на регулярной основе. Не слишком ли дорого мы за это платим по времени? Ведь есть тесты уровнями выше.

Кроме того, тесты могут выступать входной точкой при изучении кода.

Я несколько раз о таком читал, но пока не встретил человека, кто действительно бы так делал.

пишу на php столько же времени, все больше прихожу к мысли что TDD вовсе не нужен, для бизнеса абсолютно неважно работает твой юнит-тест с БД и нужно его сделать интеграционным, каков процент покрытия и тд. Бизнесу нужен BDD, желательно на Gherkin’e, как минимум в екоммерции

Есть точка зрения что это у вас, наоборот, юнитом является хрен пойми какая «логическая единица работы» вместо метода или класса выполняющего одну функцию как должнó

Не, не только у меня. Корифеи программирования об этом говорят в том числе.

В адекватной разработке когда соблюдается SRP и другие хорошие методологии, и есть хотя бы минимальный план развития продукта код как правило пишется один раз, покрывается тестами и нужды менять в нём API больше не возникает.

Это все красиво звучит на словах, либо можно найти в редких отдельно взятых компаниях. В основной массе сегодня «ажайл» и постоянное изменение бизнес-требований на всех этапах разработки.

Если повезёт, то ты никогда не увидишь непрошедший тест. Именно в этом и заключается польза.

В чем польза теста, написанного после кода, который за свою жизнь ни разу не упал?

У тебя есть два стула - чинить ломающиеся тесты, или чинить ломающийся прод.

Между юнит-тестами и продом есть еще другие тесты.

В т.ч. если тебе за них платят, то в чём проблема?

Человеческий организм сопротивляется бессмысленной на его взгляд работе, даже когда за нее платят. Гипотеза в том, что без покрытия можно ехать быстрее, без потери в качестве.

Тоже со временем к этому пришел

В чем польза теста, написанного после кода, который за свою жизнь ни разу не упал?

Польза для кого? Для тебя польза в том, что тебе заплатили за эту работу. Для владельца польза в том, что есть бизнес процессы по минимизации возможных рисков, что внушает ему какую-то уверенность, что вы макаки не потопите его бизнес своими кривыми руками.

есть еще другие тесты

И что? Ты рассуждаешь как человек, который нарушает какое-то правило ТБ потому что «есть же ещё другие правила, поэтому ничего не будет». Типа «зачем пристёгиваться если есть подушка безопасности?». Ну да пристёгиваться бессмысленно, только мешает этот ремень, ни разу не помог.

Человеческий организм сопротивляется бессмысленной на его взгляд работе, даже когда за нее платят

ЛОЛ ЧТО? Тебе вот даже не платят за то что ты трындишь на ЛОРе, но ты же трындишь. Хотя это намного бесполезнее и бессмысленнее любых тестов.

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

Тесты фиксируют текущее поведение известное авторам системы. TLD в плане юнит тестирования это с моей точки зрения очень и очень плохо и практически бесполезно, т.к. автор функционала уже его отладил и тесты ему тут ничем не помогали.

Тесты нинужны. Пусть юзеры тестят. Чай не софт для самолётов делаете. И вообще, PDT, херак-херак и в продакшон - наше всё.

Можно уточнить, что вы подразумеваете под интеграционными тестами? Условно говоря, это тест Spring контроллера вместе с БД? А зависимости на внешние сервисы - мокаются?

Хотя это намного бесполезнее и бессмысленнее любых тестов.

Он получает опыт трындежа, прокачивает устойчивость к токсичности™ и восстанавливается после тупой работы. Это очень полезное дело!

Что скажете?

Если серьёзно, то у тебя просто тесты херовые. Я тоже не понимаю, зачем тестить myClass.sum(1,1) == 2

Я тоже не понимаю, зачем тестить myClass.sum(1,1) == 2

Ну ты что, а вдруг война?

Складывается ощущение, что «code coverage» с развитием CI/CD стал вездесущ и очень часто от него попахивает карго-культом.

часто так и есть, но все зависит от задачи.

Есть определенные сферы где затраты на переписывание тестов в связи с изменением интерфеса это маленькие затраты по сравнению с пропущенным в продакшен реальным багом.

Или переполнение а у тебя UB вместо ошибки или нет. Но сходу и не скажешь, а как бы проверить? Надо наверное написать кусочек кода что бы проверить. Блин, а чего, надо каждый раз так что ли делать? Давай обзовём его тестом и пусть просто рядом в кодовой базе лежит?

Интеграционным тестам моки не нужны.

Да, да. Это, может, когда у тебя твой сервис от других не зависит. Да и моканьем я тут называю не только условный Mockito, но и поднятие всяких БД с вставкой туда каких-то предопределенных значений.

Я в ближайший год уйду из писательства кода за деньги, потому что эта сфера - сплошной маразм, долбоебизм и подверженность модным веяниям, которые пользы зачастую не несут, а только вред. К юнит-тестам тоже относится (я не говорю, что они не нужны, если вдруг кто-то неверно поймёт меня).

Разработка должна быть хобби.

Если пишешь некритичный софт, не для бортового ПО или систем жизнедеятельности, не банковский или атомный сектор, то такое прям супер-глубокое тестирование не имеет смысла

Я занимался тестированием FPGA, там на модуль (считай юнит), были конкретные требования, и чтобы проверить его соответствие нужно много времени. И там часто были несоответствия, часто проваливались тесты

Когда же 99% тестов проходят, то это хорошо. Может быть подняться на чуть более высокий уровень тестов? Вам же нужно проверять как всё работает при интеграции?

При этом я не отрицаю пользу юнит-тестов как таковых. Считаю их полезными, когда юнит устойчив и содержит в себе некую ключевую логику, которую действительно имеет смысл тестировать атомарно

Тоже так считаю

Если серьёзно, то у тебя просто тесты херовые.

Ладно бы у меня, они кругом все такие.

Я тоже не понимаю, зачем тестить myClass.sum(1,1) == 2

Ну как зачем, вдруг там на выходе 3?

полезней в своей работе property-based тесты

Все нижесказанное не касается TDD и прочего test-first.

А зачем они вам тогда? Весь сок как раз в натравливании кода на спеку, тут юнит-тесты и раскрываются.

Вы меня не услышали. Я ни слова не говорил об «инженерном проекте», я специально упомянул слово «минимальный». И не просто так упомянул модульность.

Через несколько лет разработки код может быть переписан чуть ли не целиком

Ещё раз, такое возможно только у абсолютно безграмотных команд, и это ещё надо сильно постараться.

Не, не только у меня. Корифеи программирования об этом говорят в том числе.

Неудивительно, безграмотный подход к разработке в отрасли скорее норма. Как раз среди «корифеев», которые вместо работы балаболят на конференциях, прежде всего.

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

Мой опыт говорит об обратном, но, увы, заставить вас поверить я не могу. Вы спросили - я ответил: если тесты плохо работают, проблема не в тестах, а в коде. Проще конечно выкинуть тесты чем научиться писать качественный код. Можете попробовать - потом расскажете, назовите только компанию где работаете чтобы с ней не связываться.

В адекватной разработке когда соблюдается SRP и другие хорошие методологии, и есть хотя бы минимальный план развития продукта код как правило пишется один раз, покрывается тестами и нужды менять в нём API больше не возникает.

Это все красиво звучит на словах, либо можно найти в редких отдельно взятых компаниях. В основной массе сегодня «ажайл» и постоянное изменение бизнес-требований на всех этапах разработки.

Если код спроектирован грамотно, постоянное непредсказуемое изменение бизнес-требований не приводит к необходимости постоянно весь код переписывать. В условиях аджайла, это одно из главных требований к архитектуре. Достигается это, как писали выше, в частности благодаря SRP (хоть как по мне, остальные принципы SOLID не менее важны).

Что касается юнит-тестов, то они фиксируют контракт методов/классов. Это очень важно при рефакторинге: благодаря юнит-тестам удается заранее выявить нежелательные изменения в контракте.

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

Написание юнит-тестов одновременно с кодом повышает качество кода: сильносвязную лапшу тестировать неудобно, и появляется стимул её структурировать.

Что касается юнит-тестов, то они фиксируют контракт методов/классов. Это очень важно при рефакторинге: благодаря юнит-тестам удается заранее выявить нежелательные изменения в контракте.

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

Написание юнит-тестов одновременно с кодом повышает качество кода: сильносвязную лапшу тестировать неудобно, и появляется стимул её структурировать.

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

Сама метрика «процент покрытого кода» не так важна. Важно, что эти тулзы позволяют тебе увидеть, какие части кода протестированы, а какие нет. Может так оказаться, что ты случайно не протестировал один из важных кейзов в функции, coverage report покажет тебе эти места.

ИМХО! тесты гавно, т.к. имеют смысл только для выявления особенностей среды при неизменном API, иначе чуть в сторону от этого соглашения, лёгкий рефакторинг будет порождать правки в тестах и даже поиск багов в них, тесты должны быть, но покрытие должно быть меньше 30-50%, если вы конечно не собрались замораживать продукт и покрывать только либо сложные и платформозависимые свистоперделки, надёжность при переносе которых может вызывать вопросы, либо write-only код иначе гемор - ваша жизнь. Да и слишком часто люди до маразма доходят при тестировании, проверяя даже вещи, которые просто по стандартам должны быть нерушимыми, да и не стоит забывать сломать можно что угодно и тесты не гарантируют вам что вы сможете отыскать проблему.

если тесты плохо работают, проблема не в тестах, а в коде

Они не плохо работают, они просто не работают. Потому что рефактронига как такового нет.

Это очень важно при рефакторинге: благодаря юнит-тестам удается заранее выявить нежелательные изменения в контракте.

Я не помню, когда последний раз видел рефакторинг. Код попадает в репозиторий после статического анализа и код-ревью. До изменения бизнес-требований код никто не трогает.

Ещё раз, такое возможно только у абсолютно безграмотных команд

Ты главное верь.

Давным давно на одном из проектов (у нас была пара недель) мы провели эксперимент и довели уровень покрытия юнит-тестами до 50% на уровне пакета (помню эти красивые диаграмки cobertura в jenkins-е :) ). Уже на этом уровне большое количество тестов (я их писал вместе с остальными) были реально ненужными - ну зачем, спрашивается, мне тестировать пачку getter/setter-ов.

80%? Это очень много для ЮНИТ тестирования. Такое было бы неплохо иметь для интеграционного тестирования, но на них измерять покрытие гораздо сложнее и не всегда возможно (таки просадка производительности имеет место).

PS. Адептом TDD я конечно же не являюсь и дрочевом на покрытие не занимаюсь, но знаю что нормальный код можно при желании покрыть на 95% и не тратить сколь либо заметного времени на поддержку тестов при его последующем развитии.

При тотальном покрытии юнит-тестами время на поддержку тестов таки тратится немалое (я бы сказал от 30% до 70%), но в общем - за счёт быстрой обратной связи и недопуска ошибок в прод - временные затраты на дальнейшую разработку и поддержку продукта остаются или теми же самыми, или даже уменьшаются. Но это всё не относится к юнит-тестам одного метода «шобы было» - речь именно про грамотно спроектированные автотесты.

Давным давно на одном из проектов (у нас была пара недель) мы провели эксперимент и довели уровень покрытия юнит-тестами до 50% на уровне пакета (помню эти красивые диаграмки cobertura в jenkins-е :) ). Уже на этом уровне большое количество тестов (я их писал вместе с остальными) были реально ненужными - ну зачем, спрашивается, мне тестировать пачку getter/setter-ов.

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

Если хочется красивых циферек, тривиальный код лучше просто исключать из coverage report, тогда и время на написание пустых тестов тратить не придётся.