(Статья — результат совместной работы с Максимом Степановым)

В прошлой статье мы показали, как тесты помогают найти изъяны в архитектуре. Для этого мы попытались протестировать скрипт на Python, проверяющий погоду. Нам пришлось разбить его на несколько функций в зависимости от зон ответственности, и это позволило написать несколько тестов. Но у них были существенные недостатки:

• Хрупкость

• Зависимость от внешних систем

• Невозможность протестировать пользовательский сценарий в отдельности

• Избыточное покрытие.

Чтобы написать более качественные тесты, нам придётся улушить архитектуру кода, а именно реализовать внедрение зависимостей и перейти на модульную архитектуру. Посмотрим, как именно тесты заставляют нас совершенствовать код.

(Статья — результат со вместной работы с Максимом Степановым)

Когда начинаешь писать тесты к коду, иногда возникает ощущение, что пытаешься расчесать запутанные волосы, и чем больше дёргаешь, тем больше узлов находишь. Это полезный сигнал, к которому стоит прислушиваться: плохая тестируемость подсказывает, что у кода есть изъяны в архитектуре. 

Связанный код, который сложно поддерживать и расширять, сложно и тестировать. Как сказал Боб Мартин: 

«Тестируемый код — синоним разъединённого кода»

А значит, тестируемость может быть маркером хорошей архитектуры. Именно это мы и попробуем здесь продемонстрировать.

Мы напишем тесты для примитивного скрипта на Python, который проверяет IP пользователя, определяет их регион и сообщает текущую погоду в регионе. Нас будет интересовать, как эти тесты заставят нас изменить код. Они, как расчёска, помогут нам методично разобрать проблемные места, чтобы код (как и волосы) стал гладким и послушным. Полный пример доступен здесь, каждый основной шаг находится в отдельной ветке.

В первой части статьи мы сделаем простейшее преобразование — разобъём скрипт на отдельные функции, а потом выясним, какие недостатки кода нам пока не удалось устранить. Во второй части мы от них избавимся с помощью разъединения зависимостей и модульной архитектуры. Поехали!

Почему так сложно сделать отчёт, который будет полезен и разработчику, и аналитику, и менеджеру? Написать красивую HTML-оболочку — дело не такое уж и трудозатратное. 

Но одного этого мало. Чтобы отчёт могли читать люди без навыков тестирования и программирования, он должен уметь скрывать технические подробности тестов; а чтобы им по-прежнему могли пользоваться тестировщики и разработчики, код по-прежнему должен быть под рукой, на расстоянии одного-двух кликов.

Нативные отчёты, используемые фреймворками тестирования, здесь обычно не подходят, или не предоставляют нужную функциональность «из коробки». Из опенсорсных решений, позволяющих анализировать тесты на разных уровнях, стоит упомянуть ReportPortal и Allure Report. На примере последнего мы проанализируем, что нужно, для того, чтобы сделать тесты «читаемыми» для всей команды — а в конце покажем, как эту функциональность можно расширить, если вдруг под ваш уникальный стэк её не удалось найти.

От редакторов: название «сага» для паттерна долгоживущих транзакций так прижилось, что уже есть даже в Википедии. А как возникли этот паттерн и его название? Благодаря работе 1987 года. Похоже, что она до сих пор никем не была переведена на русский, и теперь мы решили это исправить.

Долгоживущие транзакции (long-lived transactions, LLT) блокируют ресурсы баз данных в течение длительных промежутков времени и существенно замедляют выполнение более коротких и многочисленных транзакций. Чтобы решить эту проблему, мы предлагаем ввести понятие саги. LLT является сагой, если она может быть записана как последовательность транзакций, которые можно чередовать с другими транзакциями. При этом система управления базой данных должна гарантировать, что либо успешно выполняются все транзакции саги, либо выполняются компенсирующие транзакции, корректирующие частичное выполнение. И само понятие саги, и его реализация относительно просты, но с помощью них можно существенно повысить производительность. В этой работе мы анализируем различные вопросы реализации саг, в том числе запуск саг на системах, не поддерживающих их напрямую. Мы также обсуждаем приемы проектирования баз данных и LLT.