Comments 23
глубоко
более глубоко сделаю немного позже, в которой можно описать с какими именно проблемами сталкиваешься при сравнении скриншотов (на 100% процентов ли должны они совпадать и совпадают ли скриншоты на линуксе и маке, стоит ли для этого брать докер).
Данную статью решил опубликовать, т.к. многие проекты которые меня окружали, особенно фронтендеры не делают тесты и уверены что им это и не нужно, поэтому выпустил статью в общих чертах описывающую, зачем они могут пригодиться.
Данную статью решил опубликовать, т.к. многие проекты которые меня окружали, особенно фронтендеры не делают тесты и уверены что им это и не нужно, поэтому выпустил статью в общих чертах описывающую, зачем они могут пригодиться.
И вот хоть бы одна статья была, в которой бы было не бла-бла-бла как тут, а были бы собраны данные и показано — как наличие или отсутствие тестов влияет на сроки/расходы/прибыль. А иначе какое-то пустое балаболство. Show the numbers!
у меня такая статья есть, про тестирование
Можно посчитать количество баг тикетов на строчку кода допустим до внедрения тестов в проект и после.
Ну хорошо, а что если вот как посчитать: предположим, что несколько разработчиков сначала пишут логику, и только потом тесты. Тогда мы можем посчитать количество упавших тестов но только при самом первом прогоне. Из них конечно будем исключать те, которые упали по вине самих тестов. Допустим в идеале 1 тест на 1 кейс. Наконец мы представляем, что вот такой процент поехал бы дальше на прод и это собственно и есть результат измерения. Само собой для правильности придется организовать команду.
я думаю все же влияют, но в какую сторону это отдельная история.
К примеру хотелось бы сравнить 3 команды с большим количеством человек (чтобы исключить индивидуальный фактор), которые будут выполнять один и тот же проект. Только одна команда не будет писать тесты, вторая будет писать тесты только на критические места (к примеру где часто баг появляется или ключевую функциональность тестить), а третья писать тесты в районе 80% — 100% покрытия проекта. И интересно провести статистику сроков выполнения задачи, количества багов и стабильности продукта
А вообще я пишу тесты как ты и сказал для безопасности, чувствую себя спокойней
К примеру хотелось бы сравнить 3 команды с большим количеством человек (чтобы исключить индивидуальный фактор), которые будут выполнять один и тот же проект. Только одна команда не будет писать тесты, вторая будет писать тесты только на критические места (к примеру где часто баг появляется или ключевую функциональность тестить), а третья писать тесты в районе 80% — 100% покрытия проекта. И интересно провести статистику сроков выполнения задачи, количества багов и стабильности продукта
А вообще я пишу тесты как ты и сказал для безопасности, чувствую себя спокойней
Хмм… цифры будут всегда субъективны, т.к. единственный маломальский результат можно провести только на эксперименте, чтобы 2 команды кодили один и тот же проект, только одни С тестами, а другие БЕЗ и вести полную статистику их результатов. При этом обязательно чтобы команды были большие, чтобы индивидуальные показатели не сильно влияли на общий результат. Это дорого и достаточно бессмысленно, поэтому все держится на уровне ощущений.
Опять же в статье тоже опираюсь на ощущения, того что фиксить один и тот же баг тупо бесит и возвращаться в контекст не хочется и тест помогает избегать таких проблем
могу лишь предложить более конкретную статью про проблемы с тестами например при тестировании скриншотами (на 100% процентов ли должны совпадать и совпадают ли скриншоты на линуксе и маке, стоит ли для этого брать докер и прочее), если это интересно.
Опять же в статье тоже опираюсь на ощущения, того что фиксить один и тот же баг тупо бесит и возвращаться в контекст не хочется и тест помогает избегать таких проблем
могу лишь предложить более конкретную статью про проблемы с тестами например при тестировании скриншотами (на 100% процентов ли должны совпадать и совпадают ли скриншоты на линуксе и маке, стоит ли для этого брать докер и прочее), если это интересно.
Похоже на рассказы Зощенко. Автор то-ли всерьез, то-ли издевается, сразу не поймешь.
Как в банках, каждый час поломки сайта, стоит сто тысяч долларов и им любая возможность найти баг на вес золота, поэтому там покрыто тестами все вдоль и поперек!Да, это очень распространенный миф.
В теории да: у банков очень много денег — чистая правда. Поэтому они могли бы скупить лучших из лучших разработчиков — чистая правда. А вот когда теория заканчивается и начинается практика, то оказывается, что по факту разрабы в банках середнячковые, процессы убогие, про TDD никто ничего не слышал. Выделенной команды тестировщиков почти ни у кого нет. Все тестируют аналитики и бизнес-пользователи.
Имею опыт работы в 4 российских банках. Собеседовался и задавал каверзные вопросы еще в десятке банков.
И кстати, в Европе, по всей видимости, та же фигня (но тут я не работал, только на собеседованиях был).
>они могли бы скупить лучших из лучших разработчиков — чистая правда
ну на самом деле нет. Хотя я тоже работаю на банки, причем давно, и я не самый плохой разработчик, но в некоторые банки я просто не пойду — ни за какие деньги.
Ну то есть, деньги тут не решают. Или решают не все.
ну на самом деле нет. Хотя я тоже работаю на банки, причем давно, и я не самый плохой разработчик, но в некоторые банки я просто не пойду — ни за какие деньги.
Ну то есть, деньги тут не решают. Или решают не все.
я бы сказал что деньги достаточно решают. К примеру в Минске очень много Гемблинга (ставки на спорт, казино и прочее). И там сидят очень много крутых местных спецов, т.к. финансово есть куда расти, компания стабильно на плаву (лох не мамонт). Поэтому если банки в общем показывали для разрабов стабильно зарплаты чуть выше и чуть перспективнее, то не ты так твой тим лид с проекта пойдет
думаю тут дело именно в человеческом факторе. Вот к примеру я достаточно инициативный человек и когда прихожу в новую компания иницирую сразу же ряд активностей: Дев митинги (для обсуждения проблем в проекте или рассмотрение альтернативных подходов или же просто новинки обсуждаем), внедряю тесты, в текущей компании у нас mobX и с ним есть сложности, так мы на дев митингах почти все его внутренности разобрали и собираемся контрибьютить в него проектом. Так к чему я это. Зачастую весь движ на проекте, желание туда пойти, качество проекта держится буквально на паре максимально замотивированных людях. А если ты просто платишь большие з/п то вполне у вас могут осесть и все недобросовестные люди и ты пообщавшись с ними на собесе и сам туда не пойдешь, а тот же банк так и не будет понимать в чем проблема
А я вот просто девелоперам запретил баги коммиттать.
Интересная подача)
Sign up to leave a comment.
Нужны ли тесты именно вашему проекту?