#python #testing

Лекция об эффективных инструментах тестирования в Питоне от Рэя Хеттингера, разработчика ядра.

https://www.youtube.com/watch?v=ARKbfWk4Xyw&ab_channel=SFPython

Резюме:

1) всегда используйте доктесты, это мотивирует писать качественную документацию и учит вас (не говоря о других) использовать ваш же код. это настолько крутой инструмент, что не использовать его просто глупо. (я его теперь стараюсь всегда использовать). А ещё Сфинксом можно создавать красивые онлайн доки прямо из docstring.

2) не используйте модуль unittest, вместо него берите py.test: понятнее синтаксис, на 60% меньше печатания.

3) Рэй предпочитает PyFlakes вместо PyLint по причине излишней предвзятости и болтливости последнего )

4) статическая типизация не всегда улучшает читаемость кода, зачастую с ней приходится бороться дольше, чем писать сам код (чтобы убедить проверяющий инструмент). возможный выход – gradual typing.

5) интересен пример модуля, проходящего доктесты, юниттесты, имеющего 100% покрытие, строгую типизацию (проходящую проверки mypy), и всё же содержащего много критических ошибок, которые ждут своего часа, чтобы всплыть.

6) с подобными логическими ошибками помогает бороться пакет Hypothesis, который позволяет для входов функции с помощью декоратора задать стратегии (например: текст, или список целых чисел), автоматически влекущие синтез разнообразных тестовых значений, в том числе и краевых. Этот инструмент за секунды придумает и набросит вашей функции на вход столько всего самого разного и неожиданного, что сами и за неделю не составите ) В примере из доки пакет Гипотезы для текстового входа быстро находит ошибку для пустой строки, а затем и куда более нетривиальную логическую, возникающую при наличии в строке повторяющихся символов.

P.S.: у кого хватило терпения осилить мутации входов с помощью Гипотезы, велкам на следующий метауровень просветления: мутации самого вашего кода с помощью mutatest (и проверки, что сломанный код действительно вызывает падение тестов)! Тем самым автоматически проверяется качество и полнота уже ваших тестов.

#python #testing #pytest

Что делать, если у вас сотни (или даже тысячи) тестов в проекте, не ждать же сутками когда pytest их последовательно переберёт?

Ставим pip install pytest-xdist, и запускаем pytest -n auto, но и тут опасность. Часто бывает, что тесты из одних и тех же файлов/классов конкурируют за одни ресурсы - файлы, gpu, etc.

Тогда добавляем флаги --dist=loadfile или --dist=loadscope, чтобы снизить конкуренцию за ресурсы и сохранить какую-то параллельность. Но даже при таком подходе будут ложноположительный фэйлы.

Оптимальное решение: сначала запускаем тесты с разумной параллельностью не создавая отчёты, потом последовательно проходим подозрительные с этапа 1, используя флаг -lf:

pytest tests/ -n auto --maxprocesses=32 --dist loadscope && exit 0 || pytest tests/ -vv --lf