Создание модульного теста Python, который никогда не выполняется параллельно

Мне часто нужно запускать тесты с полной изоляцией. Единственный способ, который, как я обнаружил, работает последовательно, — это поместить эти тесты в отдельные классы. Согласен, что обработка конфигурационных файлов внутри тестов по-прежнему доставляет неудобства.

Для чего-то, что я делаю прямо сейчас, я также могу попробовать что-то вроде pytest-ordering для проведения тестов более детерминированным образом.

Во-первых, большинство сред тестирования, поддерживающих параллелизм, также поддерживают методы для последовательного выполнения определенных важных тестов. Например, Python Fabric поддерживает последовательную аннотацию (когда вы запускаете свой тестировать как параллельный пакет с флагом командной строки -P):

from fabric.api import *

def runs_in_parallel():
    pass

@serial
def runs_serially():
    pass

Тем не менее, я не думаю, что вы должны делать это, я думаю, что вы должны остановиться и презреть на мгновение. Следуя принципу единой ответственности, я бы сказал, что это происходит.

Вы находитесь в ситуации, когда тест, по сути, определил состояние вашего кода, он выделяет для вас небольшое пятно единства.

Что вам нужно сделать сейчас, так это понять, что у «converter.py» слишком много обязанностей, он не только выполняет некоторые сложные операции под капотом, но также несет ответственность за управление своим собственным созданием и настройкой, что, вероятно, слишком много. для этого.

Возможно, если бы у вас был объект, который может управлять чтением в этом файле, вы могли бы легко имитировать/заглушить его и создать описываемое вами условие, которое вы хотите протестировать.

Лучшей стратегией тестирования было бы убедиться, что вы тестируете непересекающиеся наборы данных. Это позволит обойти любые условия гонки и упростить код. Я бы также издевался над open или __enter__/__exit__, если вы используете менеджер контекста. Это позволит вам подделать событие, что файл не существует.

Проблема в том, что имя config_custom.csv само по себе должно быть настраиваемым параметром. Затем каждый тест может просто искать config_custom_<nonce>.csv, и любое количество тестов может выполняться параллельно.

Очистка всего набора может просто очистить config_custom_*.csv, так как в этот момент они нам не понадобятся.