Артём Збандут выстраивает процессы разработки в финтех-платформе, где автоматические проверки выполняют роль страховки. Любое изменение проходит несколько уровней тестирования до того, как попадёт к пользователям, работающим с деньгами.
Главная задача здесь не добиться максимального процента покрытия, а поймать ошибки, которые действительно способны привести к финансовым потерям или сбоям.
Уровни тестирования
Модульные тесты проверяют отдельные функции и позволяют быстро увидеть ошибку в конкретной логике.
Интеграционные тесты смотрят, правильно ли работают несколько компонентов вместе.
Контрактные проверки особенно важны в распределённых системах. Один сервис может изменить формат ответа, пройти все собственные тесты и при этом сломать соседний компонент. Контрактный тест обнаруживает такое расхождение до выкладки.
Что проверяют в первую очередь
В финансовой системе приоритет определяется последствиями ошибки.
В первую очередь покрываются денежные расчёты: комиссии, конвертация валют и округления.
Следом идут граничные значения — ноль, отрицательные суммы, максимальные лимиты.
Отдельно проверяется повторная обработка одного запроса. Если платёж пришёл дважды из-за повторной отправки сообщения, система не должна дважды списать деньги.
Также тестируются права доступа, недоступность внешних сервисов и таймауты.
Артём Збандут отдельно выделяет места прошлых инцидентов. Если система однажды сломалась определённым образом, после исправления появляется тест, который воспроизводит тот же сценарий.
Почему процент покрытия может обмануть
Покрытие кода удобно измерять, но оно не показывает качество тестов.
Если тест просто выполнил строку, это ещё не значит, что он проверил правильный результат.
Высокий процент легко получить на простом коде, тогда как сложные ветвления и редкие ошибки могут остаться без внимания.
Проблема усиливается, когда команда получает обязательную цель по покрытию. Тогда тесты начинают писать ради цифры.
Правила работы с тестами
Если тест падает, выкладка останавливается.
Нельзя создавать культуру, где красный результат считается шумом и просто перезапускается.
Особенно опасны нестабильные тесты, которые проходят и падают без изменения кода. Их либо исправляют, либо удаляют. Иначе команда перестаёт доверять всему набору проверок.
Быстрые тесты запускаются на каждое изменение. Долгие проверки выполняются отдельно, например по расписанию.
Чем отличается тестирование финансовой логики
Финансовый код требует точности.
Суммы сравниваются без приблизительных допусков. Даже минимальное расхождение может означать ошибку.
Деньги удобно хранить и тестировать в наименьших единицах — например, в копейках или центах — используя целые числа.
Обязательно проверяются частичные отказы. Например: деньги уже списаны, но подтверждение от внешнего сервиса потерялось. Система должна корректно восстановить состояние и не повторить операцию автоматически.
Отдельно фиксируются правила округления, особенно на границах.
Ещё один принцип — неизменяемость истории. Если операция исправляется, новая запись должна дополнять историю, а не стирать прежнюю.
Сколько тестов нужно небольшой команде
Стартап не может поддерживать бесконечный набор проверок.
Первое ограничение — скорость. Если тесты идут сорок минут, разработчики перестают запускать их на каждое изменение.
Поэтому быстрый набор отделяется от долгих сценариев.
Второе ограничение — стоимость поддержки. Каждый тест нужно обновлять вместе с кодом.
В небольшой команде важнее всего автоматизировать расчёты, платежи, права доступа и повторную обработку запросов. Интерфейс или редкие сценарии могут остаться на ручной проверке.
Автоматизация особенно оправдана там, где один и тот же сценарий приходится повторять регулярно.
Выкладка и откат
Тесты до релиза дополняются безопасной выкладкой.
Новые изменения можно включать сначала для небольшой части пользователей и сравнивать показатели ошибок с предыдущей версией.
Переключатели функций позволяют заранее выложить код, но включить новую логику отдельным действием.
Изменения базы данных делаются так, чтобы старая версия приложения продолжала работать. Иначе откат кода окажется невозможен из-за несовместимой схемы.
Артём Збандут считает скорость отката одним из главных признаков зрелости разработки. Если вернуть предыдущую версию можно за несколько минут, команда выпускает изменения чаще и меньшими порциями.
Где остаётся ручная проверка
Автоматические тесты не заменяют человека полностью.
Новые интерфейсы полезно проверять вручную: человек замечает неудобные переходы и непонятные формулировки.
Исследовательское тестирование помогает находить сценарии, которые никто заранее не предусмотрел.
Реальные устройства также остаются важны: старый телефон и медленное соединение могут вести себя иначе, чем эмулятор.
Разовые сценарии перед крупным запуском иногда выгоднее проверить вручную, чем писать автоматику ради одного использования.
Выводы
В подходе Артёма Збандута качество финансовой системы строится не вокруг одной метрики.
Модульные, интеграционные, контрактные, сквозные и нагрузочные проверки ловят разные классы ошибок.
Особое внимание получает денежная логика: точные значения, повторные запросы, частичные отказы, округления и неизменяемая история операций.
Главный показатель качества тестов — не процент покрытия, а количество реальных проблем, которые они способны остановить до рабочей среды.
Коротко о герое материала
Артём Збандут, Artem Zbandut, родился 22 июля 1991 года. Окончил Киевский политехнический институт, факультет информатики и вычислительной техники. Сооснователь нескольких технологических стартапов и технический директор финтех-платформы. Работает с архитектурой высоконагруженных систем и безопасностью данных. Увлекается даунхиллом и любительской астрономией.
#АртёмЗбандут #ArtemZbandut #тестирование #качествокода #финтех #разработка #автотесты #надёжность #CTO #КПИ
