Комментарии 39
Тест повторяем. Тест не ломается если приложение не поменялось
Это относится к основам генерации уникальных данных. Например, мы тестируем регистрацию. Очевидно, что если не генерировать уникальный емейл то на продакшене такой тест скорее всего не будет работать.
кстати, не очень очевидно. Во-первых, почему тест на продакшене? На продакшене тестов быть не должно вообще. Во-вторых, окей, давайте рассмотрим сценарий регистрации. Нам нужно нагенерировать пачку логинов (почт), которые мы будем пытаться регистрировать. Но если между прогонами тестов они будут меняться - тест может флапать (скажем, мы сгенерировали валидный логин или почту, но по какой-то причине тест на ней завалился, скажем, был какой-то спецсимвол). Как в этом случае грамотнее написать тесты? Все-таки генерировать некий рандомный набор входных данных, но в рамках определенных критериев? Или все-таки зафиксируем большое количество тест-кейсов и будем идти по ним? Ну, и не раскрыта тема негативных тестов. Т.е. если у нас некорректный имейл - мы тоже должны проверить, что регистрация не пройдет...
Для регистрации вы делаете тесты которые проверяют ветки сценариев, т.е. зарегался, уже есть такой логин, плохой пароль итд. Для каждого сценария достаточно одного теста.
Далее есть правила валидации мейла, и их много, для них делается юнит тест тестирующий все правила. Таким образом юнит тест проверяет правила, а интеграционный проверяет что проверка была вызвана.
Генерация случайных логинов в этом случае скорее всего не нужна
На продакшене тестов быть не должно вообще.
Почему?
тут очевидно зависит от того что тестим. скажем в банке на ПРОДе особо не потестишь.
Почему?
Потому что не посоздаешь реальных пользователей и денег ниоткуда. Уже молчу о генерации платежей и карт.
Берёте реальных пользователей, деньги и в путь.
Вы брали или вы фантазируете?
Я в 3 банках работал. Никто на проде реально не тестит автотестами.
А ещё недавно везде всё вручную тестировали.
Я работал в двух. В одном тестили на проде даже с переводами. В другом тестили read-only сценарии, но возможно будут и иные.
. В одном тестили на проде даже с переводами.
автотестами?
да. и следили за балансом, комиссий не было.
Я помню как на DevOps-конференции ребята из Monzo-банка рассказывали, что когда, например, в три часа ночи нет транзакций, то непонятно, это потому, что их действительно нет, или потому, что система лежит.
И если в течение часа не было транзакций, то они сами делали транзакцию на один фунт между своими счетами или картами, и смотрели, отразится ли она в системе.
По их словам, в изначальной версии это был механический паровозик, который проезжал с карточкой мимо бесконтактного терминала по специальной кольцевой железной дороге.
Первое, что Вы абсолютно правильно обратили внимание на важность мониторинга. С этим я абсолютно полностью согласен. Причем мониторинг не только технических параметров, но и бизнесовых.
Во-вторых, касательно примера - он какой-то странный. Дело в том, что Банк сам по себе никогда не транзачит. Транзакция всегда является сущностью, которая санкционирована человеком, ну, либо какой-то автоматизированной системой. Но вот как раз тут можно опять же закрыться мониторингом. Смотрите. Человек работает с банк-клиентом - будь это мобильное приложение, или веб сайт Банка. А раз так, то транзакция - это всегда HTTP запрос. Мы их можем считать и смотреть, что в нашей АБСке столько же реальных транзакций, сколько было запросов. ОКей. В какой-то момент времени мы могли понять, что к нам клиенты не могут постучаться. Но это решается вторым слоем мониторинга - не знаю, тот же downdetector прекрасно ловит каскадные отказы. Та же история с интеграциями по API... В конце-концов можем внедрить в приложение модуль слежения типа Sentry...
Поэтому механический паровозик, хоть и звучит круто, и как продающая история для компании, но абсолютно лишний.
Знаете, что мне сказали крайний раз в втб24 и на горячей и в отделении? Они сказали, под сафари банк-клиент работает збс, им глубоко плевать что больше он ни под одним браузом много месяцев не запускается под https вовсе или работает с косяками и в ограниченном режиме в том же гуглохроме. Который они честно предупредили, что наклали на саппорт. Сказали юзайте мобайл апп. Которое тоже ужас как кривое. Хотя на айос уверен все мб ок. Скоты, ворочая миллиардами экономят на разрабах нанимая индусов подешевше и это инфа из первых рук. Теряют миллионы клиентов из-за этого только. Уважения такому бизнесу нет. Сбер не лучше. А уж многие банки поменьше..
Согласен, проблемы есть. И не только у ВТБ. Но то, что Вы рассказываете - и к юнит тестам, ни к интеграционным тестам отношения не имеет. Это вообще отдельный класс UI тестов со своими подходами. И, увы, что ВТБ со своми многомиллионными бюджетами на разработку не может это осилить. Зато эджайл, скрам и девопс.
К тому же, если продукт дерьмо, то от того, что он стал айти продуктом, он пахнуть не перестанет. Поэтому я полностью согласен, что сначала надо думать о клиенте, о его потребностях. Формировать правильные и корректные юзер стори, а потом уже качественно это все выражать в виде продуктов...
Система чаще лежит на местах и по вине железа. И до этого никому нет дела сутками. Так что это все пыль в глаза. Как доходит до дела и у клиента пинкомат сожрал карточку или сдох всем на клиента накласть, - видел не раз. Систему надо строить с отнешений к людям, к клиенту. Когда на коленях извинились и выплатили неустойку за косяк. А потом уже ищут виноватых. А не как у нас - клиент всегда не прав.
Это все крайне скудный набор. А я упомянул как раз про сильные ограничения. Создания пользователей, выдача карт и т.д.
Поэтому и сказал что не разгонишься.
А перевод и лирика это конечно легко и на Проде. Но этого крайне мало и не проверяет важную бизнес логику.
Работал в финансовом секторе и в России и в США. И там и тут прод системы тестами были обмазаны с головы до ног. И руководство постоянно давило на то, что надо добавит ещё и ещё всех возможных и невозможных проверок как на тестовые системы, так и на продакшн.
Регулятор не позволяет. Если речь про банки.
Я уж не говорю о том, что, например, решать фейковых пользователей плохая идея, разве что есть гарантия того, что у Вас есть свой почтовый сервер, который гарантированно пользователь никогда не задействует. Либо какой-то флажок "тестовый пользователь" вводить, но тогда это ещё одна возможность получить глюки на ровном месте
Вы согласны, чтобы джун сделал тестовый перевод 100 тысяч с вашего счета на свой?
На всякий случай уточню, что речь не про А/Б или функционал, закрытый фиче-флагом. В Банках этим тоже активно пользуются... но это не те тесты, о которых речь в статье.
Я просто постарался привести простой пример. Если честно то я ОЧЕНЬ редко видел на практике что люди стартуют тесты с чистой базой - обычно стейджинг и никто его никогда не чистит
мы с базой только так и тестируем. Приводим нужные таблицы в изначальное состояние (fixture), делаем, что нужно, и проверяем конечное состояние.
Мы пишем на Джаве, поэтому обычно используем для наката датасета, и для проверки (assert'а), библиотеку dbUnit.
@TellamonidУверяю Вас, Вы круты и мы это видем очень редко )
Я не упоминал негативных тестов отдельно потому что и позитивные и негативные тесты должны удовлетворять этому же критерию IMHO
Короче, изобрели F.I.R.S.T.?
Ой, а ссылочку можете дать? Никогда про него не слышал.
Это из книги "Чистый код" Роберта Мартина. Глава про юнит тесты.
F.I.R.S.T. - Fast, Independent, Repeatable, Self-validating, Timely.
Тут я пишу в основном про end-to-end тесты, поэтому, мне кажется, немного другие критерии
А, вы про end-to-end. Для них мы перед прогоном всей пачки тестов чистим базу. И обеспечиваем независимость тестов, чтобы они могли бежать в параллель. В нашем случае достаточно, чтобы каждый тест бежал за свою бизнес-дату. И, конечно, есть отдельный тест, который проверяет, что бизнес-даты у тестов не пересекаются.
Предусмотреть все масштабы содеянного не возможно в любых случаях, можно лишь отсечь частные, руководствуясь определенными масштабами. Пользуйтесь, хотя я думаю, это сказали задолго до меня. "Даже взмах крыла бабочки на одном конце атлантики может привести к тайфуну - на другом" (с)
7 характеристик хороших тестов