Close
Содержание
Это называется integration test, потому что тестируется часть пайплайна. Препроцессинг и постпроцессинг данных вполне можно покрыть тестами. При условиях большого процента покрытия (на CI) код вполне успешно покрываеться недо-тестами и без TDD. Где-то важно покрыть критическую часть.Сейчас на проекте использую интеграционные тесты в некоторой части функциональности.
А вот что крайне полезно на такой разработке — это тесты времени исполнения, которые пишут логи о всех странностях (но по возможности не роняют). При малейшей стабилизации эти логи начинают анализироваться и всё, что в них найдено, фиксится. 3) Интеграция с третьесторонними системами непредсказуема.
Правильные тесты создают надёжный базис для верификации кода. Это такой же карго-культ, как и сам TDD для некоторых. По спекам, но это нужны спеки аж на уровне расписаных функций. А где такое бывает, если только команда не разрабатывает чисто библиотеку, я хз. Вы мешаете в кучу необходимость писать тесты и использование TDD как методологии написания тестов. «Отсидеться», пока проблемы решает ведущий инженер, тимлид или менеджер проекта не получится, а потому у кандидата должны быть прокаченные автономность и умение не дергать старшего коллегу каждые три секунды.
А ещё эти системы позволяют быстро создать отчётность о стадии готовности и качестве тестируемого продукта. Во-вторых, классическое TDD всё-таки подразумевает ООП архитектуру в стиле Java. Их задача не проверка правильности работы (это функциональные тесты), а найти список поломок в случае рефакторинга системы. Далеко не все используют экстремальное программирование с его частым рефакторингом, а тогда преимущество unit-тестов не настолько очевидно. В классическом TDD объявляется, что1) пишутся тесты до кода2) тесты должны быть проверены на то, что они не проходят3) пишется код для их удовлетворения. Да, профессионал почти наверняка напишет код без багов.
Тесты после кода это уже не TDD, нужно быть отборным мазохистом, чтобы тщательно покрыть Юнитами большой массив кода. Понятно, что есть редкие баги, которые не отловятся при использовании TDD, но их общее число снижается на порядок, а код сам по себе становится структурированным, без зависимостей потому, что по другому его не протестируешь. Как ты предлагаешь отлавливать такого рода ошибки в юнит-тестировании? Они и при функциональном тестировании могут жить годами, а приложение падать раз в год в совершенно разных местах.
Мазохистом надо быть, чтобы покрывать его тестами до написания, пока он не устоялся. А после написания — это всего лишь рутина. Видать вы не деплоили хотфикс на прод без вообще каких либо тестов.
Не имеет никакого отношения к методологии TDD, кроме собственно факта тестирования. 5) Подход «сначала тесты, затем код» — это уменьшенный вариант Waterfall’а — «сначала архитектура, затем код». И хоть оба лозунга звучат просто, понятно и логично, жизнь доказала, что на практике все далеко не так идеально. И ещё такой момент.Если 95% разработчиков не используют TDD,то и 95% проектов прекрасно работают без него.Следовательно TDD — это не панацея и без неё проекты могу тпрекрасно существовать десятилетиями. Например, консольное приложение, генератор ходов в русских шашках.
Философствование на тему нужно или не нужно TDD возникает когда качество результата работы вторично и не важно. Если качество на первом месте только TDD может привести к результату за разумное вермя. Да и вообще если нужно качество то все это будут применять одновременно. Вот например интеграция с платежным сервисом на 150 процентов выполняет бизнес-задачу проведения оплаты картой.
К сожалению, мы не можем дать исходники, этот продукт пока разрабатывается для внутреннего использования, но если будет интерес, то с командой напишем обзор о технических решениях при построении инструмента. Путь был не прост, первая версия была написана все теми же инноваторами, разворачивалась на локальном сервачке, обкатывали этот инструмент часть специалистов по тестированию департамента Front-end и Mobile. Была боль, были муки, но оно того стоило.
Хотя как по мне дело не в этом, а в том что QA не заменяет юнит тесты. Опишу двумя словами — тестирование имплементации — если ваш тест попадает в эту категорию то он просто дублирует функциональность системы версионирования кода. Обязанности и требования к кандидату могут отличаться в зависимости от опыта работы. На позициях Trainee и Junior основные требования — это представление жизненного цикла ПО, знание базовых принципов тестирования, понимание принципов корректности работы приложений и знание клиент-серверной архитектуры. После успешного пилота мы передали разработку с департамента тестирования в департамент разработки, где нам выделили front-end / back-end разработчиков.
Будет полезна QA, Team Lead и всем участникам разработки, которые хоть как-то вовлекаются в тестирование. Только чуть иначе — «функциональное» тестирование (и опять это кривое использование термина — вообще-то все тесты функциональные; лучше говорить о крупноблочном) ловит ошибки не только на стыке, но и во внутренних реализациях. А уже имея факт ошибки можно спускаться ниже и обкладывать вплоть до тестов отдельной функции всё, что подозрительно. Годится только для тех случаев, где дизайн с самого начала очевиден. Иначе каждая очередная итерация потребует удвоенной работы и объема кода. А остальное как-то из пальца…Есть разработчики, которые пишут достойный код и без тестов, а есть и те, которые и с тестами становятся звёздами на говнокод.ру и поднимают людям настроение в минуты заслуженного отдыха.
1) вызов show_error не является критическим требованием.Вы обязаны проверить что ваша программа делает в “негативном сценарии”. А в негативном сценарии она так же будет вызывать и show_error. Шазам и вы получили покрытие на шару. Пример сферический, но легко разширить где там вовнутри логика тож будет. В ответ можно привести кучу примеров задач с другой стороны спектра, где сеть и дб дёргаются по минимуму. Условный легковесный Markdown редактор.
Иногда можно living specification делать, но это включает сильную обратную связь на эту самую спецификацию, которая меняется и уточняется на ходу. На более низких уровнях тестирования связь с формальными спецификациями мало смысленны. Потому что не умеют, учиться влом, стимула нет, а когда приходят в команду таких же неумех, то и вводить тесты не получается. Это если тесты в рамках «технического долга».
Скорее наоборот, энтерпрайз спокойно относится к простоям по причине «ой, что-то сломалось» и «ой, а как оно должно работать», которые вяло текут в переписке по несколько недель кряду. Стартапы же ожидают более активной разработки (и изменений) — как раз конёк тестов — не обязательно TDD, но хоть каких-то. 2) Тесты пишут программисты, а как мы все знаем, программисты — бесплатные системы управления тестированием посредственные тестировщики. Хорошему программисту, просто в голову не придет, что можно «так» использовать его метод/класс/программу. Но они как комментарии — должны покрывать принципиально важные и неочевидные места, а не каждую строчку кода. Вот как раз в таких высоконагруженных случаях можно намного больше в канареечных релизах и прямиком на продакшине тестировать.
Ну всякий BDD, cucumber-ы там со RSpecами и т.п., в особо запущенных случаях — Fitnesse. Составляется specification by example в соответствующем диалекте, по выполнению задания текст связывается с тестовым кодом и получается living documentation, она же спецификация. Обычно в процессе имплементации удобно спецификацию эту подправить, что вызывает обратную связь.
Вкупе с продакшеном втроем они просто не могли поделить два разрешенных соединения с бекендом. Про второй тестовый сервер я узнал совершенно случайно, когда имптех остановил сервис на втором и отрапортовал об этом в тот момент когда я смотрел работающий и не останавливающийся лог первого. Так похоже что у вас и был свой вариант mutation testing’a — просто без использования существующего mutation framework’a и с заведомо заданными мутантами. Самая стремная техника, но позволяет понять как фиксить баги правильно. Кстати тесты вообще слабо помогают понять что делает функция, намного больше помогает хорошее именование.
Грустно вводить ход, потом вручную составлять список ответов… Куда проще написать генератор, а потом просто один раз внимательно проверить его результаты и скопипастить в тест. Потому что термин TDD я встретил впервые в книгах Кента Бека по экстремальному программированию, а с дальнейшей эволюцией термина я не очень следил. Но в случае тяжёлого теста начинать с его написания мне несколько неудобно, да и не суть важно. Под верификацией тут подразумеваются все методы, начиная с простой ручной верификации глазами (code review), извините за каламбур.
