Комментарии 73
Разработчики не умеют тестировать
Они не просто не умеют тестировать. Они тестируют то, что работает.
Все дело именно в том, что разраотчик писал этот код. Если бы ему пришла в голову мысль, что здесь что-то может пойти не так, он бы поправил это в коде. А, если такая мысль при разработке не пришла, то почему она придет при тестировании?
Разработчики должны писать внутренние тесты. Но они не для проверки, а для будущей разработки — рефакторинга, доработки.
А внешние тесты, для проверки должен и писать внешний человек — тестировщик.
По большому счету, если дефект попадает в прод, это вина всей команды, поэтому команда — и тестировщики и разработчики, должны писать необходимые тесты, чтобы гарантировать, что дефекты не дойдут до клиента.
Они тестируют то, что работает— согласен, но автор статьи писавший провокационный заголовок, об этом забыл и сосредоточился на профитах:
- облегчить жизнь тестировщикам (ошибка — их человекочас обычно дешевле чем человекочас разработчика)
- ускорить выпуск релизов за счет устранения регресса (ошибка — разработчик покроет тестом фичу, но интегрально приложение развалится в неожиданном месте)
Мораль: от регресса производимого тестировщиками не уйти
Автор же тестировщик. Он описал ситуацию, глядя со своей колокольни. Если говорить о юнит-тестировании, то пожалуй соглашусь с автором. Разработчик должен четко документировать свои публичные интерфейсы и покрывать их тестами. В первую очередь это поможет самому понимать, какое поведение ожидается от той или иной функции и убедиться в корректной обработке пограничных случаев.
В такой парадигме жизнь тестировщика не упрощается, меняются задачи которые он решает, на его стороне остаётся экспертиза в тестировании.
Но в данном случаи речь речь не про облегчение или усложнение жизни или уход от регресса, как правило регресс можно просто покрыть автоматизаций, были бы свободные руки и желание. Речь о процессе в целом, в данном случаи нужно оценивать общий профит или его отсутствие, а не конкретного звена :D
Но в данном случаи речь речь не про облегчение или усложнение жизни или уход от регресса, как правило регресс можно просто покрыть автоматизаций, были бы свободные руки и желание. Речь о процессе в целом, в данном случаи нужно оценивать общий профит или его отсутствие, а не конкретного звена :D
Это если сначала код писать.
А какая разница?
Если сначала написать тесты, то они будут тестировать то, что будет работать. То, что не будет — все равно останется за бортом.
Если сначала написать тесты, то они будут тестировать то, что будет работать. То, что не будет — все равно останется за бортом.
Отчего же? Я пишу не только положительные случаи, но и пачку quick property based. Написать их легко, кейсы придумывать не надо. Только свойства описывать, которые и есть инварианты программы.
Речь не о том, положительные мы случаи тестируем или отрицательные, а о том, что разработчик о них знает и в коде обработал. Неожиданные для себя варианты он не проверит.
Так же ж… Я про то, что мешает добавлять quick тестирование, которое сродни whitebox fuzzing.
Пример: допустим, у нас есть вес коробки, на который мы где-то в коде делим.
Если разработчик сообразил, что кто-то может указать там 0, то он и проверку в коде сделает и тест с 0 напишет.
Если не сообразил — не сделает ни того, ни другого.
Если разработчик сообразил, что кто-то может указать там 0, то он и проверку в коде сделает и тест с 0 напишет.
Если не сообразил — не сделает ни того, ни другого.
Мы начали с того, что разработчик если будет писать тесты, то напишет только на положительные кейсы.
Собственно, если начинаешь с тестов, то нет никакого "сообразил-не сообразил", есть описание спеки в виде тестов. Часть их них превратится в инварианты для более глубокого тестирования перебором.
Если же разработчик не в состоянии начать со спеки, то это уже фигак и в продакшн, тут медицина бессильна.
Что Вы называете «положительными кейсами»? Возможно, мы просто разной терминологией пользуемся.
В спецификации написано — «вес коробки». Всем же известно, что в реальной жизни вес положительный. Так?
В спецификации написано — «вес коробки». Всем же известно, что в реальной жизни вес положительный. Так?
Немного не так работает. Начав с теста поймёшь, что нет описания веса коробки — тест не написать. Придется писать письма, топать ножками и дорабатывать спеку и переносить в тесты. Где система типов помощнее, там сразу в тип.
Тут же дело не в том, что это вес коробки, а в том, заметит разработчик это граничное условие или нет.
Хорошо, если условие такое очевидное — 0. А если 3,14? Или -1?
Да, в коде (или в ТЗ) будет деление (например) на x+1. Если разработчик это заметит, то он и в коде проверку напишет и в тесте. Если нет — ни там, ни там. И это не зависит от того, что он пишет сначала — код или тесты.
Т.е., тесты, написанные разработчиком, не найдут его ошибки.
А значит, нужно независимое от разработчика тестирование.
Вот все, что я хочу сказать.
Но, так-то, да. Хорошо бы сначала написать подробное ТЗ со спецификациями, потом тесты, потом код, потом документацию. Где-то в идеальном мире…
Хорошо, если условие такое очевидное — 0. А если 3,14? Или -1?
Да, в коде (или в ТЗ) будет деление (например) на x+1. Если разработчик это заметит, то он и в коде проверку напишет и в тесте. Если нет — ни там, ни там. И это не зависит от того, что он пишет сначала — код или тесты.
Т.е., тесты, написанные разработчиком, не найдут его ошибки.
А значит, нужно независимое от разработчика тестирование.
Вот все, что я хочу сказать.
Но, так-то, да. Хорошо бы сначала написать подробное ТЗ со спецификациями, потом тесты, потом код, потом документацию. Где-то в идеальном мире…
НЛО прилетело и опубликовало эту надпись здесь
Писать тесты перед ещё удобно в том, что даёт сразу понимание удобно будет итоговое API для использования или нет. Бывает так, что архитектурили, но реальное применение выявляет нюансы и требуется модификация API. Когда пишешь тест до, собственно, кода как раз эти моменты и всплывают.
Я не спорю с полезностью написания тестов до кода.
Я только про то, что тесты все равно будут написаны только на те случаи, что обработаны в коде. Не выявят ошибок, неожиданных для программиста.
Я только про то, что тесты все равно будут написаны только на те случаи, что обработаны в коде. Не выявят ошибок, неожиданных для программиста.
Ну так от тестов не требуется покрытия 100% неожиданных ситуаций.
Типов тестов много разных и каждых из них решает свои задачи.
Ну не выявят неожиданных ошибок. Выявит тестировщик или пользователь, будет заведен дефект при закрытии которого появится новый тест. Обычный процесс.
Типов тестов много разных и каждых из них решает свои задачи.
Ну не выявят неожиданных ошибок. Выявит тестировщик или пользователь, будет заведен дефект при закрытии которого появится новый тест. Обычный процесс.
Так о том и речь. Разработчик — не выявит. А тестировщик — вполне может.
Поэтому требовать от разработчика написания тестов именно для проверки новой функциональности — бессмыслено.
Поэтому требовать от разработчика написания тестов именно для проверки новой функциональности — бессмыслено.
Всё зависит от разработчика, бывают разработчики которые консультируют тестировщиков о том как нужно тестировать, бывают те кто вообще не умеют тестировать, их могут консультировать тестировщики(:
Также новая функциональность может быть разная по сложности тестирования, к примеру если добавляется новый фильтр в приложение и нет ни одного теста на другие фильтры — в этом случаи могут возникнуть вопросы по тестированию. И наоборот, если добавляется новый фильтр и уже есть тесты на все остальные фильтры — в этом случаи написать тесты будет просто. Чем больше кодовой базы в автоматизации, тем проще писать последующие тесты на новый функционал(:
Также новая функциональность может быть разная по сложности тестирования, к примеру если добавляется новый фильтр в приложение и нет ни одного теста на другие фильтры — в этом случаи могут возникнуть вопросы по тестированию. И наоборот, если добавляется новый фильтр и уже есть тесты на все остальные фильтры — в этом случаи написать тесты будет просто. Чем больше кодовой базы в автоматизации, тем проще писать последующие тесты на новый функционал(:
То что не каждый разработчик умеет тестировать это правда и одна из основных сложностей, по этому на тестировании остается валидация тестов. Как это работает, разработчик пишет тесты и отдаёт в тестирование человкочитаемый отчёт c подробными шагами, с этой задачей отлично справляется Allure. Тестировщик смотрит на покрытие, и если тестов недостаточно то отправляет на доработку. С каждой итераций качество тестов растёт, а количество переоткрытий из-за багов уменьшается.
Про Unit-тесты, хорошее замечание, но как показывает практика часто они вовсе отсутствуют.
Про Unit-тесты, хорошее замечание, но как показывает практика часто они вовсе отсутствуют.
А, если такая мысль при разработке не пришла, то почему она придет при тестировании?
Тестировщик подскажет :)
Можно сначала согласовать приемочные тесты командой, потом, разработчик разрабатыает пишет тесты, потом exploratory тестирование тестировщиком, если находит глюки разработчик фиксит и пишет тесты.
То, что кто-то пишет тесты не означает что он их придумывает с самого начала.
А, если такая мысль при разработке не пришла, то почему она придет при тестировании?
Есть непроверенная гипотеза, что сам процесс написания теста вынуждает подумать о граничных условиях. Кроме того, написанный тест позволяет быстро прогнать свой код на разных входных данных — мне случалось так ловить ошибки столь же элементарные сколь и неочевидные
это антипаттерн "позитивное тестирование". Далеко не все разработчики ему подвержены
Ошибка.
Именно так и происходит: когда разработчик начинает писать тест, его мозг переключается из "созидательного" в "критический" режим, и он начинает придумывать разные ситуации, в которых его код может сломаться. Это помогает не только тесты написать, но и тут же улучшить код, не дожидаясь всего этого долгого процесса релиза/установки/тестирования/багфикса.
См. https://www.youtube.com/watch?v=8u6_hctdhqI&feature=youtu.be&a
1. Разработчики пишут функциональные тесты.
2. Тестировщики пишут системные тесты.
3. Сценарии тестов (и функциональных и системных) обсуждаются тестером и разработчиком, чтобы:
2. Тестировщики пишут системные тесты.
3. Сценарии тестов (и функциональных и системных) обсуждаются тестером и разработчиком, чтобы:
- не пропустить какой-нибудь кейс;
- не писать дорогой системный тест на то, что можно проверить функциональным;
- подложить соломку в том месте, где в будущем потенциально может что-нибудь сломаться (когда есть какие-нибудь хитрые взаимосвязи фронта и бэка).
UNIT тесты должен писать разработчик, тестировщик зачастую не может грамотно написать тесты для какого-то класса, написать моки и тд. так как не знает нюансов
Функциональные тесты может и тестировщик писать и разработчик.
Системные тесты пишет тестировщик
Тестировщики должны придумывать тестовые случаи, о которых PM и разработчики даже не подумали бы – собственно для этого они и нужны.
Функциональные тесты может и тестировщик писать и разработчик.
Системные тесты пишет тестировщик
Тестировщики должны придумывать тестовые случаи, о которых PM и разработчики даже не подумали бы – собственно для этого они и нужны.
Всё так, но всё же кажется что разработчиков и PM недооценивают, они тоже могут генерить интересные сценарии. Другой вопрос что нам нужно основной упор делать не на хитрость сценариев, а на то с чем может столкнуться пользователь. Если в этом месте возникнут трудности, тестировщик всегда может помочь сфокусировать внимание на главном(:
Есть старый холивар на тему, кто же должен писать тесты: разработчики или тестировщики. Вроде как если в команде есть тестировщики, то логично, что тесты пишут они, правда?Подобная формулировка вопроса заранее предполагает холивар, либо автор просто не разбирается в различных видах тестирования.
Ничего плохого нет в том, что разработчики пишут тесты и то, что они осознанно/не осознанно пишут тесты под работающий код. Ведь тесты пишутся не только для того, чтобы найти баги, но и для того, чтобы при последующей разработке, внедрении новой фичи или, банально, рефакторинге не внести регрессию.
И тесты которые отлавливают регрессию разработчики вполне себе успешно пишут.
Другое дело, что я предпочитаю у себя в командах разделять тех кто пишет код и тех кто этот код покрывает тестами. Так эффективнее получается.
И да, я не против тестировщиков :)
И тесты которые отлавливают регрессию разработчики вполне себе успешно пишут.
Другое дело, что я предпочитаю у себя в командах разделять тех кто пишет код и тех кто этот код покрывает тестами. Так эффективнее получается.
И да, я не против тестировщиков :)
Тесты должны писать все.
Разработчику полюбому придется писать тесты, иначе как понять, что то, что написано, как минимум работает. Плюс хороший разработчик должен уделить какое-то время, перед тем как передвигать задачу в review, "а что если произойдет то, или это", нестандартные какие-либо ситуации, написать тесты на эти ситуации, проверить ожидаемое поведение.
Разработчик сможет протестировать низкоуровневые части, тестировщику на это потребуется слишком много времени и головной боли.
Тестировщик, в свою очередь, может отлично протестировать высокоуровневые вещи, написать интеграционные тесты на том же python.
Часто разработчик может не обладать достаточным профессионализмом в той сфере, в которой работает компания. И тот третий человек, кто разбирается в узкой специализации, но не разработчик или тестировщик, вместе с описанными выше профессионалами, в идеале, имхо, должны работать вместе, создавая идеальный продукт.
А) аналитики должны писать тест-кейсы, а не все остальные.
Б) тесты разные бывают. Есть те, где только разработка справится. Есть те, где разработчики только мешают.
Часто аналитиков совсем нет на проекте(:
Аналитик — бизнес-аналитики или тест-аналитики? Бизнес-аналитик — должен писать требования, тест-аналитик — описывать тест-кейсы. Это если мы говорим о документации. А если говорим о коде или инструментах — то ответственность разработки — юнит-тесты (в идеале, если возможно, сперва прочитав описанные тест-аналитиком тест-кейсы), а ответственность тестировщиков — все остальные виды и уровни тестирования (ручного и автоматизированного, функционального и нефункционального)
Кто требования продумывает, тот тест-кейсы и должен писать, бо он знает, что ему нужно получить в итоге и как убедиться в том, что достигнут нужный результат.
Профессия тест-аналитика идëт следом, как и профессия тест-дизайнера.
В наше время всë то, что касается тестирования, сведено к одному юниту, вроде как бизнес-оптимизация получилась. Заявить "А я тест-дизайнер" уже кагбэ глупо, что там дизайнить, вас что, пэирвайз укусил? Просто протестируйте это чертово приложение…
В башнях-близнецах, которые схлопнули 9/11, сидели очень грамотные бизнес-аналитики, которые для Reuters софт и требованиями, и тест-кейсами обкладывали. Проходить их было скучно, бо очень уж детально всë и годами ничего не изменяемое, но это были, наверное, лучшие тесты ВООБЩЕ. Но те аналитики умерли, а новые башни не выстроили.
В обычном IT аналитики такого уровня не нужны так же, как и отдельные тест-дизайнеры, поэтому [дальше ваша схема без изменений]…
Кто требования продумывает, тот тест-кейсы и должен писать, бо он знает, что ему нужно получить в итоге и как убедиться в том, что достигнут нужный результат.
И часто вы видели людей, которые придумывая требования — продумывает не только основой набор сценариев, как должно работать, но и сценарии, как обрабатывать не стандартные ситуации? Т.е. понято что в итоге спрашивать придется у этих людей, но должен же быть кто-то, кто задаст такие вопросы?
Профессия тест-аналитика идëт следом, как и профессия тест-дизайнера.
В наше время всë то, что касается тестирования, сведено к одному юниту, вроде как бизнес-оптимизация получилась. Заявить «А я тест-дизайнер» уже кагбэ глупо, что там дизайнить, вас что, пэирвайз укусил? Просто протестируйте это чертово приложение…
Проверить одно и то же 10 тестами или 50-ю? Действительно, чего там дизайнить.
В башнях-близнецах, которые схлопнули 9/11, сидели очень грамотные бизнес-аналитики, которые для Reuters софт и требованиями, и тест-кейсами обкладывали. Проходить их было скучно, бо очень уж детально всë и годами ничего не изменяемое, но это были, наверное, лучшие тесты ВООБЩЕ. Но те аналитики умерли, а новые башни не выстроили.
Не очень понял к чему тут это.
В обычном IT аналитики такого уровня не нужны так же, как и отдельные тест-дизайнеры, поэтому
… поэтому х-к, х-к и в продакшен.
И часто вы видели людей…
Редко. Но мы говорим о том, как оно должно быть, или о том убожестве, которое бытует в современных офисах?
Люди, которые умеют работать с требованиями, тестируют их намного лучше тестировщиков. И обрабатывают сценарии во все стороны, и находят нестандартные ситуации намного лучше, чем сторонние тестировщики, бо они в теме (в отличие от).
В итоге сложные решения не тестируют всеобъемлюще, для бизнеса Happy path это good enough. Каждое решение имеет свою цену («Just avoid holding it in that way» Steve Jobs).
Действительно, чего там дизайнить.
Много чего.
Я раньше состоял в секте свидетелей пэирвайза, который каким-то хитрым образом позволяет вместо тысячи тысяч тестов сделать всего условно 30, при этом волшебным образом обеспечивая полное покрытие и счастье всех тестировщиков. Потерял на этом здоровье и квартиру, от меня ушёл мой несуществующий пёс и весь мой биткоин превратился в простой молдавский лей.
Но потом я прозрел, бросил эту секту неудачников и записался в секту тестировщиков, подозрительных к пэирвайзу (она ближе к метро, очень удобно). Там мне стало понятно, что само по себе тестирование — ерунда, и что всё тестирование начинается и делается там, где работают с требованиями. Это первоисточник, из которого начинаются и верификация, и валидация, и S.M.A.R.T, и тест-дизайн, и как работают все техники тест-дизайна, и прочее.
Вступайте в нашу секту аналитики в тестировании!
х-к, х-к и в продакшен.
Да, в большинстве случаев приложение имеет заказчика, у которого средства могут исчерпаться в любой момент.
Заказ на разработку почти никогда не делается в режиме «У нас есть мешок денег, сделайте нам ПО». Это больше похоже на подписку на ипотеку — мы хотим что-то, что в принципе будет стоить большой мешок, давайте начнём это делать частями, частями же и будем оплачивать.
Разработка действует в том же стиле. Вон, Роберт Мартин писал, что в доисторические времена программисты очень обрадовались идее ватерфолла, мол, наконец-то придёт порядок, сперва будет работа с требованиями, затем кодирование по ним (а не по внезапным добавкам с изменениями), затем релиз, граждане довольные расходятся по домам. Но нет, не работает это дело, и не будет работать по ряду причин, среди которых первое — человеки. Всегда приходится что-то куякать в продакшн и надеяться, что не поломается.
Затем приходит поколение, которому с самого начала втолковывают, что надо писать софт ровно до того места, как он пройдёт юнит-тесты (не факт, что адекватные), и на этом объявлять задачу выполненной. В прод.
Затем приходит поколение, которое закомментирует уже эти юнит-тесты, бо они раздражают и мешают работать. Сразу в прод. Там фреймворк, там леший бродит, мы туда не вмешиваемся.
Где и кому (и для чего) во всей этой схеме нужны тестировщики?
Система без обратной связи работает быстрее, но теряет контроль (какой то закон кибернетики). Повышение производительности убирая тестировщиков это что-то из приемов эффективного менеджмента. Пару месяцев гарантированно будут рост и премии, главное потом вовремя свалить с проекта.
Системные тесты пишет тестировщик, т.к. чтобы заметить некоторые кейсы на этом уровне, нужен сторонний не замыленный взгляд со стороны. Функциональные тесты могут писать как разработчик, так и тестировщик. А вот UNIT тесты — только разработчик, т.к. в некоторых случаях может понадобиться использовать метод белого ящика (например, тестирование базового пути).
Я смотрю на это так: отдельный тестировщик — это разновидность парного программирования. Дело не в том, кто лучше кого что-то делает и умеет, важно в первую очередь то, что это ДРУГОЙ человек со своим не замыленным взглядом.
А может дополнить идею до полной системы?
Тесты должна писать разработка.
Прод должно писать тестирование.
Конечно, всё в меру. В случае с тестами от разработчиков в этой статье кейс рассмотрен. В целом, профит есть. И как я думаю, прежде всего от плотной коммуникации между разработчиками и тестировщиками. Запросто, можно представить как тестировщик, глядя на результаты тестов, предлагает разработчикам решение фичи, с определённой степенью детализации. А для этого он должен погрузится в устройство прода поглубже с помощью/обучением от разработчиков.
Тесты должна писать разработка.
Прод должно писать тестирование.
Конечно, всё в меру. В случае с тестами от разработчиков в этой статье кейс рассмотрен. В целом, профит есть. И как я думаю, прежде всего от плотной коммуникации между разработчиками и тестировщиками. Запросто, можно представить как тестировщик, глядя на результаты тестов, предлагает разработчикам решение фичи, с определённой степенью детализации. А для этого он должен погрузится в устройство прода поглубже с помощью/обучением от разработчиков.
Есть такое понятие — разделение труда. Один пишут код, другие его тестируют, при этом разработчик без блокировок продолжает делать фичи/фиксить баги. Одни пишут бэкенд, другие параллельно пишут фронтенд. Одни меняют в машине свечи, другие параллельно делают на ней шиномонтаж.
Должны быть прозрачные стандарты, тренинг на работу по стандартам и совместное усилие.
Встречал когда тесты перекидывали на тестировщиков.
Разработчики писали небрежный код зная, что тестировщики отловят.
Встречал когда тесты вешали на разрабов. Саботировали — добавляли на тесты неадекватное время, чтоб не делать скучную работу.
Важен тренинг и диалог между тестером и разрабом, когда разраб при работе над тикетом выбирает тестировщика и в паре закрывают тикет.
Получалось продуктивно.
Встречал когда тесты перекидывали на тестировщиков.
Разработчики писали небрежный код зная, что тестировщики отловят.
Встречал когда тесты вешали на разрабов. Саботировали — добавляли на тесты неадекватное время, чтоб не делать скучную работу.
Важен тренинг и диалог между тестером и разрабом, когда разраб при работе над тикетом выбирает тестировщика и в паре закрывают тикет.
Получалось продуктивно.
Пишу все тесты правмо в коде. Зачем вообще разделять тесты с кодом?
каждая строка имеет условие для выпадения в ошибку
github.com/mpak2/bmf/blob/master/bmf.cpp
каждая строка имеет условие для выпадения в ошибку
github.com/mpak2/bmf/blob/master/bmf.cpp
Дело в том, что тестов обычно больше, чем кода. По крайней мере для некоторых участков кода. Иную строчку покрывает N тестов. Поэтому держать тесты прямо в коде просто не получится.
Большой плюс тестов внутри проекта это то что, если какое то изменение в коде проекта требует фикса тестов, чтобы они были актуальны, это разработчику будет сделать проще. Также не всегда тесты могут быть в отдельном проекте, например при автоматизации приложений под Android используя espresso возможна только в тесной связке с кодом приложения.
Пару мыслей разработчика по этому поводу.
Разработчики уже тестируют свой код. И я сейчас не про юнит тестирование. Я работаю в сфере, где юнит тестирование не возможно.
Но все разработчики проверяют свои модули на определенных тестовых данных.
Берут типичные модели запросы и прочее и тестируют свою программу. Более того. От части это правда, что разработчику проще писать тесты. Они видит всю цепочку взаимодействий и может исходя из нее предположить ошибку.
Но против того, чтобы на него и возложить эту ответственность есть 3 НО.
Отсутствие комплектности
Как правило люди до серверов, а иногда и после сеньоров. Работают на одном конкретном модуле. И разрабатывая один модуль, ты знаешь только его, поверхностно знаешь остальные модули, и даже не знаешь как тестировать свой код на взаимодействия с ними? Какие там могут быть опасные ситуации? Какие негативные данные от туда могут прийти?
Да не знает никто. И по опыту скажу.
Как только пишется взаимодействие двух модулей, жди 100500 ошибок. Будет вот так.
В то время как даже джуниор тестировщики уже начинают работать с программой комплексно. То один модуль то другой модуль, идут по пользовательским цепочкам и т.д.
И если разработчик может еще тестировать свой модуль. Тестировать ВСЮ систему он не способен.
НО. Для тестирования нужен свежий взгляд. Один человек должен проверять другого человека. Именно по этому есть Альфа тестирование и бета тестирование. Помимо массовости это в первую очередь дает взгляд будущих простых пользователей. Люди ошибаются в первую очередь не в коде. А в гипотезах. Я думал что пользователь может ввести цифры. А он еще может ввести буквы.
НО. Тестирование — все же не свойственное занятие для разработчика. Да он может писать тесты. Он может хоть версткой заниматься, что я ему как начальник скажу то он и будет делать.Но это во-первых нервирует его, как и любая не свойственная работа. А самое главное тест который сделает тестировщик за час, разработчик сделает за 3 часа. А платить ему надо как разработчику.
Понимаете?
Это очень дорого заставлять разработчика писать тесты.
Ровно по этой причине ни один стартап не может позволить себе «разработку через тестирование». И написание юнит тестов на каждый метод класса. На написание и поддержку нужно безумное количество часов. Цена ошибки копейки по сравнению с затратами на это.
Вот 3 «НО». Но я согласен что разработчиков хорошо бы учить тестированию. Это ускорит разработку. Но заменить разработчик тестера не может.
Разработчики уже тестируют свой код. И я сейчас не про юнит тестирование. Я работаю в сфере, где юнит тестирование не возможно.
Но все разработчики проверяют свои модули на определенных тестовых данных.
Берут типичные модели запросы и прочее и тестируют свою программу. Более того. От части это правда, что разработчику проще писать тесты. Они видит всю цепочку взаимодействий и может исходя из нее предположить ошибку.
Но против того, чтобы на него и возложить эту ответственность есть 3 НО.
Отсутствие комплектности
Как правило люди до серверов, а иногда и после сеньоров. Работают на одном конкретном модуле. И разрабатывая один модуль, ты знаешь только его, поверхностно знаешь остальные модули, и даже не знаешь как тестировать свой код на взаимодействия с ними? Какие там могут быть опасные ситуации? Какие негативные данные от туда могут прийти?
Да не знает никто. И по опыту скажу.
Как только пишется взаимодействие двух модулей, жди 100500 ошибок. Будет вот так.
В то время как даже джуниор тестировщики уже начинают работать с программой комплексно. То один модуль то другой модуль, идут по пользовательским цепочкам и т.д.
И если разработчик может еще тестировать свой модуль. Тестировать ВСЮ систему он не способен.
НО. Для тестирования нужен свежий взгляд. Один человек должен проверять другого человека. Именно по этому есть Альфа тестирование и бета тестирование. Помимо массовости это в первую очередь дает взгляд будущих простых пользователей. Люди ошибаются в первую очередь не в коде. А в гипотезах. Я думал что пользователь может ввести цифры. А он еще может ввести буквы.
НО. Тестирование — все же не свойственное занятие для разработчика. Да он может писать тесты. Он может хоть версткой заниматься, что я ему как начальник скажу то он и будет делать.Но это во-первых нервирует его, как и любая не свойственная работа. А самое главное тест который сделает тестировщик за час, разработчик сделает за 3 часа. А платить ему надо как разработчику.
Понимаете?
Это очень дорого заставлять разработчика писать тесты.
Ровно по этой причине ни один стартап не может позволить себе «разработку через тестирование». И написание юнит тестов на каждый метод класса. На написание и поддержку нужно безумное количество часов. Цена ошибки копейки по сравнению с затратами на это.
Вот 3 «НО». Но я согласен что разработчиков хорошо бы учить тестированию. Это ускорит разработку. Но заменить разработчик тестера не может.
Согласен, писать Unit-тесты и тестировать свой код это хорошая практика, но не всегда так. В проектах где высокое качество кода описаный выше подход будет иметь одну эффективность, в проектах где качество кода ниже ценность данного подхода будет выше. Про замыливание глаза также согласен, но хорошей практикой является что PR разработчика проверяют его коллеги, в данной подходе они будут еще проверять код тестов. Также в результате прогона тестов будет сформирован отчёт с детальным описание шагов, который в свою очередь проверит тестировщик и если нужно подсветит моменты на которые нужно дописать тесты.
Я работаю в сфере, где юнит тестирование не возможно.
Почему?
Потому, что система построена на тесном взаимодействии с API другого, написанного не нами продукта — Autocad.
То есть фактически 90% функций не будут работать если эта программа не запущена. С точки зрения методологии юнит тестирования, все внешние объекты должны эмулироваться стабами или моками, ну не суть.
Эмулировать работу этой внешней подсистемы, задача непомерно сложная, фактически соизмеримая с написание это самой системы.
При этом даже если это все эмулировать то нет никакой гарантии, что ты эмулируешь правильно. Потому что фактически, тестироваться будет не реальная система. А твоя эмуляция.
Но предположим мы это эмулировали. Выясняется что продукт тоже развивается. Каждый год у него выходит новая версия. И переход кода на новую версию это целое событие требующее существенного времени. Но не все же клиенты переходят на новую версию? Значит нужно поддерживать старые. ПОтому что клиенты ой как не хотят переходить на новые версии.
И вот мы например поддерживаем версии автокада с 2012 по 2020.
Это 8 версии. При этом
12-14 версии компилируются 2012 вижуал студией.
14-16 компилируется 15 студией.
16-18 2017 студией.
2019 компилируется 19 студией.
Это не мы наркоманы. Это так устроено апи автокада. Старые апи не модифицируются и не совместимы с новыми студиям.
Получается нужно эмулировать моками и стабами все внешние компоненты.
Модифицировать эмуляцию под каждую конкретную версию.
Написать юнит тесты с учетом конкретной версии. И поддерживать все это.
Ну скажем так. ̶П̶р̶о̶щ̶е̶ ̶з̶а̶с̶т̶р̶е̶л̶и̶т̶ь̶с̶я̶.̶ приходится писать комплексные тесты. А в коде вместо тестирование юнитов. Тестировать инварианты через assert() каких либо величин в дебаге.
То есть фактически 90% функций не будут работать если эта программа не запущена. С точки зрения методологии юнит тестирования, все внешние объекты должны эмулироваться стабами или моками, ну не суть.
Эмулировать работу этой внешней подсистемы, задача непомерно сложная, фактически соизмеримая с написание это самой системы.
При этом даже если это все эмулировать то нет никакой гарантии, что ты эмулируешь правильно. Потому что фактически, тестироваться будет не реальная система. А твоя эмуляция.
Но предположим мы это эмулировали. Выясняется что продукт тоже развивается. Каждый год у него выходит новая версия. И переход кода на новую версию это целое событие требующее существенного времени. Но не все же клиенты переходят на новую версию? Значит нужно поддерживать старые. ПОтому что клиенты ой как не хотят переходить на новые версии.
И вот мы например поддерживаем версии автокада с 2012 по 2020.
Это 8 версии. При этом
12-14 версии компилируются 2012 вижуал студией.
14-16 компилируется 15 студией.
16-18 2017 студией.
2019 компилируется 19 студией.
Это не мы наркоманы. Это так устроено апи автокада. Старые апи не модифицируются и не совместимы с новыми студиям.
Получается нужно эмулировать моками и стабами все внешние компоненты.
Модифицировать эмуляцию под каждую конкретную версию.
Написать юнит тесты с учетом конкретной версии. И поддерживать все это.
Ну скажем так. ̶П̶р̶о̶щ̶е̶ ̶з̶а̶с̶т̶р̶е̶л̶и̶т̶ь̶с̶я̶.̶ приходится писать комплексные тесты. А в коде вместо тестирование юнитов. Тестировать инварианты через assert() каких либо величин в дебаге.
Обычно рекомендуют архитектуру ports and adapters. Не надо эмулировать автокад, надо делать порт у вашего приложения, который декларирует только то подмножество интерфейса, которое нужно именно ему от автокада.
Отдельно пишутся интеграционные тесты на адаптеры (на то, что они выполняют контракт порта)
Есть и такая теория. Но это все равно больше про то, когда у тебя есть своя программа покрытая тестами. И на 10% она использует чужое АПИ. и его тоже хочется протестировать. Тогда можно и адаптеры запилить и все прочее. Не спорю.
Но в данном случае это 90% работы конкретно с этим апи и где-то там внутри есть отдельные функции. Это скорее даже не АПИ а полноценный фреймворк. С Системой классов и сущностей от которых надо наследоваться. То есть фактически все тесты и будут интеграционными.
А поскольку они все связанны с графическим представлением объектов. Уже само по себе трудно построить условия. Потому как условия очень часто визуальные.
Ну я хочу нарисовать трубу. Подаю в автокад данные, он кода ошибки нет все норм. А трубу не нарисовал. Какой тест тут сделать?
Ну как бы если кто-то скажет у нас есть миллионы долларов, и годы на разработку. Да возможно это сработает. Ну никто так не говорит)
Но в данном случае это 90% работы конкретно с этим апи и где-то там внутри есть отдельные функции. Это скорее даже не АПИ а полноценный фреймворк. С Системой классов и сущностей от которых надо наследоваться. То есть фактически все тесты и будут интеграционными.
А поскольку они все связанны с графическим представлением объектов. Уже само по себе трудно построить условия. Потому как условия очень часто визуальные.
Ну я хочу нарисовать трубу. Подаю в автокад данные, он кода ошибки нет все норм. А трубу не нарисовал. Какой тест тут сделать?
Ну как бы если кто-то скажет у нас есть миллионы долларов, и годы на разработку. Да возможно это сработает. Ну никто так не говорит)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тесты должна писать разработка (?)