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

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

• Хрупкость

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

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

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

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

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

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

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

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

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

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

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

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

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

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