Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.
Вопрос выше, на проекте где участвую (что-то вроде админки на ангуляре) был выбран минимальный процент покрытия юнит-тестами в 90%. Не многовато ли?
Всегда думал, что надо граничные условия тестировать, а не количество строк
Количество строк это косвенный показатель, но далеко не основополагающий как по мне.
Вопрос выше, на проекте где участвую (что-то вроде админки на ангуляре) был выбран минимальный процент покрытия юнит-тестами в 90%. Не многовато ли?
Для ФЕ могут быть свои моменты.
Сугубо из моей практики, для БЕ (покрытие по строкам):
— меньше 60% равносильно отсутсвию покрытия тестами. Надо много работы КуА
— 85% легко достижимо и может быть покрыто качественными тестами (теми которые проверяют бизнес-логику, реальные сценарии)
— 90% — уже проще работать по ТДД, без ТДД будет уходить на тесты много времени.
— 95% — это уже или разработка ведется по ТДД. Или будет много синтетических тестов, что значит что при изменении какого-то куска вам прийдется вибросить очень много (в пересчете на покрытие) тестов
— 100% — у ваших разработчиков очень много свободного времени.
Еще хорошо бы настроить какое-то мутационное тестирование, это поможет понять нужно ли «обучать» команду писать тесты.
В проектах на Go хорошим считается 70%, так как 30% всех проектов занимает
if err != nil {
return err
}
Возьмите 10 Винду, уже два месяца 1809 запустить не могут. Каждые полгода ее релиз кошмарит все виндовое комьюнити. Я не знаю, какой там процент покрытия. Но я уверен, что у мелкомягких работают лучшие КюА и процент покрытия там высокий. Результат — полная ЖОПА!!!
Люди слідують новітній методології — ашоббуло-дрівен-девелопмент.
Винда это проект которому 30+ лет с 50+ миллионами строк С/C++ кода над которой работали тысячи человек, в котором еще нужно обеспечивать совместимость с кучей API, библиотек, драйверов, железа, и все разных версий и т.п. Ясен пень, что там со скоростью и качеством разработки там все очень плохо.
100% чего? Времени разработчика? QA-инженера? Менеджера?
Денег клиента, очевидно!
Маразм крепчал
А что подсказывает тебе твой собственный опыт ? Можно ли исключительно на юнит тестах организовать continues delivery ?
а чому 90 ? а чому не 91 ? цифра з потолка яка нічого не скаже
90% може покрити всі ексепшини, котрі ніколи не виникнуть, а happy path не покрити. В такому випадку ваші тести принесуть якусь цінність ?
Насчёт вопроса минимального покрытия: все методы у которых логика ветвиться и больше двух строк. Лямбды тоже за строку считаются.
Дело не в проценте, а в логике. Есть должны показывать выполнение логики. Покрывать тестами редирект и дто смысла 0. Тоже с билдерами и прочими. Все что гарантировано компилятором — тоже. Но если в коде есть if — хороший повод покрыть этот код тестами.
Если после покрытия будет 50% значит так и будет. Если будет 100 — значит пишу библиотеку. В основном же задачи тривиальны, и юнит тестов не требуют.
0, надо метод рефакторить. Но, получатся, 11. И да, тестировать, даже если не юнит тестами, все равно нужно :)
В Java, в идеале нужно включать Checkstyle -> cyclomaticComplexity на 8 или 10 и получать подзатыльник за такие методы :)
добавил про CyclomaticComplexity.
Как избавлюсь от if’ов? Зависит от метода, языка.
Весьма странный вопрос.
Мдамс. Приведите пример, товарищъ
Самый банальный пример: метод сохранения в бд и перед ним проверка что данные валидны, типа ифы и сейв, создаются валидаторы по одному на иф, добавляются в качестве зависимости и вызываются в цикле. Функционал не изменился, ифов нет
От условий, если они есть, избавиться нельзя, а вот от условных операторов в своем коде можно
Их тестировать станет легче
Все разделено на юниты, их легко тестировать, совокупное количество усилий будет намного ниже, чем тестировать неразделенное
тестирование метода юнит тестом не включает тестирование внутренностей того что вызывают
я то понял, а ты видимо нет. печально
я могу это перефразировать понятнее, но «округлить» мысль «нужно тестировать все, кроме самых элементарных методов» далее примеры того что он считает элементарным
я имел ввиду, что если ты тестируешь метод, не нужно тестировать методы которые вызываются внутри тестируемого метода. Оно должно подчинятся контракту. у него должны быть свои тесты, которые это проверяют, и т.д.
сложно пишешь, даже это сообщение надо было осознать «зависимости нужно мокать, а не тестировать в одном тесте с целевым методом»
Может быть. Мне казалось что это априори итак должны знать. Где-то делают не так? :)
в большинстве проектов тесты не делают вообще => многие могут не знать ничего
берешь и тестируешь, что непонятного? Как с камнем говорю.
Я ему про аномалии, он мне про хабар ©
— А потом что?
— А потом я в патруле ходил мимо того места. Только нога на дереве висит, да мокрое пятно на земле. Она там по-моему до сих пор висит...
на этом флудильню закрываю, потому что объяснения не вышло.
согласен, либо нормально тестировать, либо никак, полумеры дают полурезультаты
Угу и поэтому сча подавляющее большинство компаний выпускают по с кучей багов
Если тебя кто-то реально заставит тестировать все возможные варианты прохождения через все классы, при том что ты разбил их правильно, у меня для тебя плохие новости. В реальности так никто не делает.
и? товарищ не понимает как тестировать, если в коде лямбды? или что если разбить на методы, можно тестировать отдельно все?
мда... Тестировать нужно все. Но не нужно тестировать всеми возможными способами. Товарищ явно не понимает что такое тестирование
Товарищъ совсем запутался. Юнит тесты должны тестировавать только код в своем методе. Если ты разбил 10 условий на два метода по 5 условий, у тебя получится меньше юни-тестов на класс, а не больше.
А вот тестить каждый возможный вариант прохождения через все классы — это да, свихнутся можно. Но обычно такого разработчика увольняют раньше.
А пример х>y это не 10 условий никак
Да вот глядя со стороны — как бы видится, что запутался именно ты. Или под «покрытием тестами» понимается не реальная проверка всех возможных состояний системы, а исключительно некий набор хэппи пассов, который разраб сам себе придумал.
Что косвенно подтверждает:
А вот тестить каждый возможный вариант прохождения через все классы — это да, свихнутся можно.
У тебя 4 функции, в каждом 4 if, одна функция вызывает другую. У тебя 25± тестов или 200+?
Если не больше 30, то ты придумал себе что-то чего я не говорил
Хорош схоластикой заниматься.
Покрой нам тестами простую С-шную функцию printf, а я тебе буду накидывать пачками по 5 путей, которые твои тесты не покроют. И смогу это делать очень долго, поверь.
Сколько платить будешь за то что я тебе эти тесты пилить буду?
Рыночная зп по результатам собеседования..
«Мы вам перезвоним»
реальная проверка всех возможных состояний системы
Это по определению невозможно, т.к. это intractable problem. Где-то придется остановиться и провести черту — типа, тут мы тестируем изолированно (unit test) и тут мы тестируем изолированно (unit test), еще разок протестируем пару сценариев вместе (integration test) и будем надеяться, что все остальные кейсы автоматически верны.
Вот именно!
Поэтому мне и непонятны люди, козыряющие тут терминами вроде «100% покрытие тестами» и на очевидные вопросы несущие какую-то чушь в ответ.
Если у тебя 10 if’ов подряд в одном методе, то чтобы корректно протестить все эти условия, тебе нужно 10^2 тестов (все возможные комбинации). Если у тебя 10 классов с одним условием каждый и коррекной инкапсуляцией и coding-to-interface, тебе нужно 2*10 тестов, чтобы проверить все возможные комбинации. Как-то так.
та не пытайся, этим людям объяснять чем отличается юнит тест от интеграционного невозможно, а про код стайл вообще лучше не начинать
вообще-то нет, лапша в одном методе и она же разнесенная на классы будет проверяться одинаковым количеством юнит-тестов, отличаться будет только количеством усилий и кода, чтобы получить 10 во 2 степени ты из хорошего кода исключил малозначительные вещи типа проверки порядка вызова зависимостей и реакцию тестируемого класса на различные варианты работы зависимостей, а в лапшевом варианте наоборот включил, а теперь толкаешь это как «хороший код можно меньше тестировать»
Welcome to engineering. Естественно, чтобы протестировать программу досконально, необходимо приложитьэкспоненциальное усилие. Но ты на то и зовёшься инженером, что должен уметь находить компромиссы — и находить их в разумных местах (это ключевое). Я утверждаю, что десять условий в одном классе гораздо более подвержены возможности взаимного влияния, чем те же десять условий, разнесенные в 10 разных классов и связанные исключительно через интерфейсы. Доказательство довольно простое — десять условий в одном методе имеют гораздо больший общий скоуп (переменные-члены и локальные). Естественно, некоторые виды взаимных влияний необходимо тестировать — и для этого у нас есть интеграционные тесты, пирамида тестов и твой здравый смысл.
отрефакторенный код не отличается от оригинала ничем кроме форматирования и расположения операций по частям программы, как бы ты их не расположил фактическое число проверок не изменится, это просто невозможно
«Число проверок», как я уже сказал, зависит исключительно от тебя и твой оценки рисков конкретного участка кода. 100% тестируемости (я не о покрытии) не достичь. Код, в котором различные фрагменты имеют бОльший общий скоуп — по определению более рисковый. Decoupled код — менее рисковый и в общем случае позволяет снизить «число проверок» до линейного вместо экспоненциального. Что не так?
100% тестируемости достижимы, но требуют скила от всех, кто пишет код. Покрывать только рисковые места это нездоровый компромисс, применяется часто, но в этом подходе нужна армия мануальных тестеров, чтобы избежать этого надо покрывать полностью все и интеграционные тесты ещё потом наворачивать
Я не уверен, что понял тебя правильно. Когда ты говоришь о «100% тестируемости», ты имеешь в виду именно 100% тестируемость всех состояний системы (что практически невозможно) или 100% покрытие кода?
Достичь 100% покрытия тестами — синтаксического или семантического — возможно и нужно к этому стремиться, и здесь пока ничего лучше TDD не придумали.
Говорю о покрытии всех возможных веток кода, что ты подразумеваешь под всеми состояниями не сильно понимаю
Вероятно, Андрей рассматривает тестируемую систему как некий конечный автомат со множеством состояний.
Добавлю, что 100% тестируемость в трактовке Андрея (вплоть до математического доказательства корректности работы алгоритма) вполне себе требуется и достигается в определённых отраслях — военка, космонавтика, авионика. Но это — дорого, если не сказать — адски дорого. Поэтому в обычном «кровавом энтерпрайзе» мы подобных подходов и не наблюдаем, поскольку цена ошибки на несколько порядков ниже, и 100% тестируемость попросту не оправдана экономически.
не хочу показаться занудой, но не 10^2, а 2^10
Штирлиц очень близок к провалу
— А ты правда программист?
— Да.
— А скажи что-нибудь по-программистски!
В основном же задачи тривиальны, и юнит тестов не требуют.
Смешно.
Тесты нужны только для того чтобы убедить заказчика что все хорошо. Если 90% его убедят, значит нормально.
Меня бы и 100% не убедили, юнит тесты меня не впечатляют.
В этом случае цифра взята не с потолка, а от менеджмента. Так что нет, не сильно много.
Если бы эту цифру определили сами разработчики то у меня бы возникли большие вопросы к их квалификации
Если бы эту цифру определили сами разработчики то у меня бы возникли большие вопросы к их квалификации
из разряда «думаешь не так же точно как я?! — некомпетентен!»
?
По твоему 90% это адекватно?
По-моему адекватно юнит тестами близко к 100%, и один автомашин тестер на каждые
Именно об этом и говорю
Та нет, вопросов к вашей квалификации у меня куча
еще, видимо, у тебя вопросы ко всем кто пишет по тдд — тупо все неадекваты, да? :)
Не тебе мне на «ты» писать. И вставлять маты в мою речь, когда их там нет тоже не стоит. И юнит тесты в тдд пишут, если они нужны. Ими не ограничиваются.
Так что возращайся под мост и не возращайся на доу
Во во:) и чего вы такой злой в этот чудесный выходной день :)
кто злой? :) я просто троллям не улыбаюсь
Так он не троль вовсе, просто у всех свои взгляды на тестирование :)
альтернативно-адекватные? :D
Альтернативно-альтернативные :) я вот у себя на проекте , пока только могу в узком кругу единомышленников похаять 70 процентов покрытия , ибо его реально за уши притянули!
А на полноценный крестовый поход мне мой шеф индульгенции не даст :(
100% звучит здорово, но у меня любой процент этих самых тестов будет вызыватьвопрос, так как это число не показывает, а что собственно тестируют эти тесты?
Поэтому я сторонник Того что надо ориентироваться на качество , а не на количество , иначе все сводиться к тупо говно-юнит-тестам задача которых сводиться подергать строчки кода, а не проверить как это работает
а что собственно тестируют эти тесты?
это очень большая тема, я не смогу ответить кратко
Поэтому я сторонник Того что надо ориентироваться на качество , а не на количество , иначе все сводиться к тупо говно-юнит-тестам задача которых сводиться подергать строчки кода, а не проверить как это работает
качество беспорно основа любых юнит-тестов, но количество тоже очень важно или не будет полноты
Окей , остановимся на том , что лучшее враг хорошего :)
На моем прошлом проекте я получил грандиозный опыт, оказавшись в ситуации когда весь мпнеджмент был на мой стороне , а вся команда в которой я работал были в оппозиции , официально конечно нет, но не официально было очень тяжело. И дело было как раз в тестах:)
На прошлом проекте? Долго потом там работалось? :)
Год там отработал , я просто очень спокойный и на многое могу забить:)
Если мы когда-нибудь будем работать вместе — напомни тебя не огорчать :)
ну я бы предложил что юнит-тесты пишу я на все и все бы выиграли, ну а вообще знакомая ситуация: программисты не хотят писать юнит-тесты потому что:
1) не умеют писать тесты
2) не умеют писать тестируемый код
3) в принципе не хотят ничего делать
с 3й группой все понятно, 2я группа это те, кто рассказывают про то что солид с паттернами это просто модно, а практического смысла нет,
а вот группа 1 самая печальная и многочисленная, вроде бы все делают правильно и все у них должно быть хорошо, но все знания о юнит-тестах это подготовить данные, вызвать метод и сделать проверку, причем даже так и есть, но подготовка данных и зависимостей тестируемого класса у многих это какой-то кромешный ад, которые еще и ломается при любом чихе, столкнувшись с этим многие начинают считать что юнит-тесты трата времени: повторное написание того же кода что есть только в профиль, которое потом еще мешает этот код менять. для таких программистов становится откровением что идеальный юнит-тест в блоке арренжа не содержит ничего, да и вообще состоят из
Если вы/ваша компания работает по принципу — сделал, отдал и забыл и заказчик не требует качество, то да, тесты особо не нужны. Ну реализовали вы фичу, прошло 3 цикла мануального тестирования/баг фикса и все ок. Так работает приличная часть аутсорса. Но если вы должны продолжительное время сопроваждать и развивать код или вы работаете в продуктовой компании, то в недалеком будущем без тестов вам будет очень тяжко.
разговор шел о юнит тестах, собственно я и не уточнял каждый раз. И теперь каждый считает что нужно передернуть и вырвать фразу из контекста? Бред. Никто не говорил что надо делать без тестов.
Юнит тесты — онанизм. Интеграционные — вот что действительно важно.
Интеграционные тесты — онанизм. E2E — вот, что действительно важно.
Осталось найти третьего,кто считает что е2е онанизм и важно лишь вручную все протыкать
Есть пирамидка тестирования и нужно делать именно так, а все остальное бесполезные полумеры
тогда и четвертого, чтоб «мануальные тесты — онанизм. юнит тесты — вот что действительно важно»
зачем тесты платить тестерам, если есть ранний доступ )
Все тесты — онанизм, главное чтоб бабло молча платили.
иррелевантно
Угу. Ровно до того момента, как оказывается, что полный цикл интеграционных тестов занимает 30 часов. (14 дней в одном проекте)
полный цикл интеграционных тестов занимает 30 часов. (14 дней
"Ваши интеграционные тесты — говно. Вы ничего не понимаете в интеграционных тестах" © Татьяныч
:)
80% lines , classes — часто применяемая метрика
Константин, вы уверены, что речь идет именно о 90% покрытие юнит тестами? В ангуляре есть два разных инструмента для тестирования:
Дальше о каком уровне покрытия идет речь:
Если же не углубляться в ваш конкретный случай, то мое мнение о JS/TS коде:
#немоё
Early one morning, a programmer asked the great master:„I am ready to write some unit tests. What code coverage should I aim for?”
The great master replied:
„Don’t worry about coverage, just write some good tests.”
The programmer smiled, bowed, and left.
...
Later that day, a second programmer asked the same question.
The great master pointed at a pot of boiling water and said:
„How many grains of rice should I put in that pot?”
The programmer, looking puzzled, replied:
„How can I possibly tell you? It depends on how many people you need to feed, how hungry they are, what other food you are serving, how much rice you have available, and so on.”
„Exactly,” said the great master.
The second programmer smiled, bowed, and left.
...
Toward the end of the day, a third programmer came and asked the same question about code coverage.
„Eighty percent and no less!” Replied the master in a stern voice, pounding his fist on the table.
The third programmer smiled, bowed, and left.
...
After this last reply, a young apprentice approached the great master:
„Great master, today I overheard you answer the same question about code coverage with three different answers. Why?”
The great master stood up from his chair:
„Come get some fresh tea with me and let’s talk about it.”
After they filled their cups with smoking hot green tea, the great master began to answer:
„The first programmer is new and just getting started with testing. Right now he has a lot of code and no tests. He has a long way to go; focusing on code coverage at this time would be depressing and quite useless. He’s better off just getting used to writing and running some tests. He can worry about coverage later.”
„The second programmer, on the other hand, is quite experience both at programming and testing. When I replied by asking her how many grains of rice I should put in a pot, I helped her realize that the amount of testing necessary depends on a number of factors, and she knows those factors better than I do — it’s her code after all. There is no single, simple, answer, and she’s smart enough to handle the truth and work with that.”
„I see,” said the young apprentice, „but if there is no single simple answer, then why did you answer the third programmer ‘Eighty percent and no less’?”
The great master laughed so hard and loud that his belly, evidence that he drank more than just green tea, flopped up and down.
„The third programmer wants only simple answers — even when there are no simple answers ... and then does not follow them anyway.”
The young apprentice and the grizzled great master finished drinking their tea in contemplative silence.
апиридил ((
90% логики (сценариев использования) или строк кода?
Если ничего не напутали и речь действительно о 90% покрытия кода именно unit testами — лучше подальше держаться от таких проектов. А то прийдется кроме того что баги постоянно чинить так ещё тесты править, ну а багов меньше от таких тестов не станет.
интересно, что вы планировали с ответами делать
Как определить минимальный процент покрытия тестами?
Math.random().toFixed(2) * 100
Math.random().toFixed(2) * 100
=>
Math.random().toFixed(2) * PI
Это отлично. Значит заказчик богатый дурачок и любит бросать бабки на ветер.
По моему слова богатый и дурачок взаимоисключающие.
Людина може бути генієм в одній ґалузі, але повним дятлом — в іншій. Тому, зустрічаються багаті буратінки, які процес ідеальної розробки бачать через призму маркетингового буллщиту, та в багатьох ситуаціях намагаються «натянуть сову на глобус». А виконавцям шо? Зайвий раз переконувати замовника, що він фицькає гроші на якусь непотрібну дічЪ — ризикувати втратити замовника взагалі, адже він може знайти когось, хто за франкліни зробить вигляд, що сповідує ту саму, єдино можливу трушну «релігію».
Схоже що я вже забув що таке «mom and pop shop». Таких філософів треба відстрелювати.
Коли вже тут у сусідньому треді перемивають кістки тетяничу, не можу не згадати:
© www.artlebedev.ru/kovodstvo/sections/87
Клиент, со своей стороны, совершенно не обязан быть профессионалом по общению с дизайнерами. Он, как правило, австралопитек в вопросах визуальной культуры. Зато он добился результатов в своем деле, иначе у него не было бы повода идти к дизайнеру.
.....
Когда клиент просит изобразить в логотипе земной шар, дизайнер, боясь потерять пятьдесят долларов, делает, что велено. Если бы эта ситуация была придумана, вокруг нас не было бы такого количества знаков с земными шарами. Не то чтобы метафора планеты была плохой. Просто она не подходит компании, чей бизнес — установка жалюзи."
Так і живемо.
Тёма как обычно — рассказывает про других, но забывает о себе. Вспомнил тут его феерический высер насчет кондиционеров и задумался — а почему «гуру дизайна», являющийся полным австралопитеком в вопросах вентиляции и кондиционирования, считает себя вправе давать рекомендации в категоричном тоне.
воу-воу, о чем речь? люблю срачи и унижение
Та вот не помню в деталях, видел репост в фб где-то летом. Чувак говорил с позиции человека, убежденного, что все считают кондиционеры способом получить свежий воздух.
А, да вот — tema.livejournal.com/1189037.html
Сначала много бугурта о том, что люди юзают кондеи вместо открывания окон (нет).
Потом бугурт, ччто люди ссут открыть окно во время работы кондея (сжечь прибор, пытаясь охладить улицу, не очень прикольно).
И так и не додумался до кейса, когда сначала воздух впускают через окно, а потом его кондеем охлаждают (как поступают 100% моих знакомых пользователей кондиционеров).
Помню в конце
Ну дык. Инструкцию читают, когда все уже сломано, и никакие советы по починке не помогли.
Сейчас вот стиралку выбираю, интересует отсутствие вибрации при отжиме. По статистике форумов оказалось, что подавляющее большинство покупателей не знает о транспортировочных болтах сзади машинки, которые надо выкрутить, и о которых написано на первых страницах инструкции.
Это еще ничего. Недавно купил новую стиралку LG. Установку сделал сам и по инструкции. При стирке больших вещей начинает прыгать. В техсапорте давали советы опять таки из инструкции, но ничего не помогает. И тогда мне пришла в голову гениальная мысль погуглить... Оказалось что я не один купил эту ошибку by design
Мда. Попадос. В моем случае неприемлемо, ибо за машинкой будут коммуникации, об которые биться совсем не желательно.
Он раскачивается по бокам, затем срабатывает защита и сбавляет обороты, но тоже мало приятного.
какая модель-то? сложно загуглить, интернет полон жалоб на прыгающие машинки, но впервые слышу, чтоб проблема не решалась выравниванием
Model #WM3670HWA выравнивание не фиксит проблему, но амортизаторы по бокам делают работу. Вобщем, если не использовать режим отжима bulky/large, то проблем нет.
ну почему сразу дурачек, просто человек верит в анализ покрытия кода больше чем того следует)
Если каждая фича имеет хоть один тест, то это 100%. Так должно быть для крупного проекта. Медленно в начале, но потом окупается.
ты бы , раб божий , не изволил беспокоиться, а то на анефему еще себе наговоришь тут
Я отвык от такого стиля. Это юмор или пост совковое православие?
Это печалька , ты же чепуху сказал , а самое печальное , что сказал ее безапелляционно и уверенно.
а я таки подброшу , причем на полном серьезе
так вот , процент может быть указан, хоть 110% но никакой анализатор покрытия кода, никогда не сможет проверить качество этих тестов, а если ориентироваться просто на покрытие тестами кода, то это все скатиться просто в желание подержать строчки кода в твоем тесте , чтобы увеличить процент покрытия, а уж что оно там тестирует, никто париться не будет
Кеп? )
Якщо серйозно, на жаль, згоден із кожним словом.
Бачив кейси, коли треба було будь-якою ціною заткнути Сонар (ТС, до речі, якщо вже повстало питання «як?», візьміть тулзу на замітку), а чи хоча б там щось перевіряється експектами, чи то просто в тупу йде пробіг по рядкам коду і хай воно все виконується як хоче із результатом «какбохпошльот» — то вже було не суттєво :)
таки оказывается, что очевидные вещи для некоторых людей остаются самыми не очевидными и кто то продолжает упорно (упорото) ориентироваться на ту цифру и аппелировать к ней когда речь идет о качестве
о очевидные вещи для некоторых людей остаются самыми не очевидными
и кто то продолжает упорно (упорото) ориентироваться на ту цифру
и аппелировать к ней когда речь идет о качестве
coverage <> testing
покрытие кода даёт в лучшем случае проверку соблюдения контракта написанного кода,
т.е. подтверждение того, что оно работатет как планировал программист.
Но это — только часть того, что должно быть проверено.
т.е. подтверждение того, что оно работатет как планировал программист.
я бы даже это поостерегся говорить, ибо обычно, обычно что вижу я, в лучшем случае это happyPath сценарий который программист гонял всю дорогу пока писал этот метод/функцию
з.ы. а видел я вообще откровенную дичь, когда в методе производятся манипуляции над сущностью с кучей полей и программист в своем юнит тесте проверяет что объект таки есть и все , тест пройден, в саму сущность он заглянуть и что то там проверить он на контракте написанного кода вертел, конечно же)
ну так программеру и ревьюверу выговор с занесением в грудную клетку
Мне vp of engineering не разрешает 3,14здить программистов, так и сказал, Алекс только сила слова и убеждения :)
Тогда сила слова и убеждения :)
хех, как Чак Норис уже... если сам Кожаев написал такие тесты, то значит они такие и нужны :)
я бы даже это поостерегся говорить, ибо обычно, обычно что вижу я, в лучшем случае это happyPath сценарий который программист гонял всю дорогу пока писал этот метод/функцию
з.ы. а видел я вообще откровенную дичь, когда в методе производятся манипуляции над сущностью с кучей полей и программист в своем юнит тесте проверяет что объект таки есть и все , тест пройден, в саму сущность он заглянуть и что то там проверить он на контракте написанного кода вертел, конечно же)
это потому что реквайрменты не нужны, документация не нужна,
джавадоки не нужны, мануальный тестинг ой-некогда.
Главное чтоб быстро
lines чи conditionals?
а мутатційні тести?
а ну пострибай?
а якщо знайду?
Нормально.
В Salesforce на уровне платформы стоит минимальный лимит в 75%. Если покрытие меньше — работай над кодом. Но я лично для себя стараюсь держать как можно больше. Иногда под 100% получается.
Александр Шевченко
Oleksii Pavlov
Bogdan Shyiak
Yegor Chumakov
anonymous
anonymous
Yegor Chumakov
Андрей Литвинов
Андрій Плотніков
Oleg Zarevych
Андрій Плотніков
Александр Шевченко
Андрей Балагута
Dmytro Lapshyn
Andriy Maletsky
TechnoBarbarian
Alexander Gatsenko
anonymus ps
Alex Koshterek
Dmitry Bugay
Włodzimierz Rożkow
schwarzlichtbezirk
Illia Khabibrakhmanov
Алексей Лукьяненко
Nikita Galkin
Alex Fogol
Roman Tretyak
Alex Fogol
Андрей Литвинов
Дмитро
Євген Козлов
Дима Дима
Oleksii Pavlov
Gremlin
Andrii Muzychuk
163 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів