Безусловно тестирование полезно. Всегда приятно иметь и модульные, и интеграционные, и сквозные (end-to-end) тесты в наличии. Однако на практике практически всегда приходится искать компромисы между написанием кода и написанием тестов, и вполне очевидно, что приоритет смещается в сторону написания кода.
Интенсификация разработки выливается в дефицит тестов, и в целом, такая ситуация выглядит оправданной. Многочисленные рефакторинги кода, иногда и изменение бизнес-логики могут являться вполне себе аргументами для того, чтобы отложить тестирование до момента, когда основные процессы в коде приобрели стабильные очертания.
Как же в таком случае можно повысить эффективность написания тестов? Мы предлагаем подход, при котором в первую очередь тестируются основные процессы. Причем такой процесс тестируется целиком, проходя через разные части кода, а иногда и компоненты системы. pytest тест-фреймворк позволяет параметризовать входные данные процесса и проверить результат на выходе, использовав минимум кода. Одним из преимуществ такого подхода является то, что если какие-то участки основного процесса меняются, изменения в тестах потребуются минимальные. Кроме того, нередко можно встретить ситуацию, когда функция вызывается считанное число раз в коде, а формат входных данных таких функций однозначно известны. Например, логика инкапсулирована в какой-то функции, функция является частью более глобального процесса и вызывается только в нем. Тестирование таких функций отдельно не добавляет эффективности в сравнении с тестированием основного процесса, которому функция принадлежит.
В целом подобную методологию можно сжато сформулировать как:
- покрываем тестами основные рабочие процессы целиком (т.е. сам процесс выступает модулем для тестирования, иногда межкомпонентным)
- при наличии ресурсов ориентируемся на coverage и дополняем unit тестами остальной код
Кстати, в ecosystem54 для автоматического создания документации мы используем подход, базирующийся в первую очередь на основных процессах целиком (flow). Ocновной процесс (flow) указывается в описании функций и методов. Затем сборщик проходит по описаниям и строит блок-схему всего процесса целиком.
Также читайте:
- В DataScience проекте бардак? Как это исправить и не допускать в будущем
- Шифрование дисков Ubuntu22.04
