Я тестирую функцию, которая в начале вызывает loguru.logger.add("file.log"). Это вызывает проблемы во время выполнения pytest. Файл записывается во временный каталог и, таким образом, используется другим процессом (старой доброй Windows), когда происходит очистка.
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'path/to/tmp_dir/file.log'
Одним из решений является установка патча loguru.logger.add для каждого теста. Но это приводит к большому количеству повторяющегося (шаблонного?) кода. Для многих тестов мне не нужно ссылаться на logger.add, просто нужно исправить его, чтобы тест запускался.
@patch("loguru.logger.add")
def test_one(mock_logger_add):
...
# Useful to check, but don't want to call this in EVERY test
mock_logger_add.assert_called_once()
@patch("loguru.logger.add")
def test_two(mock_logger_add):
...
# No need to check mock_logger_add, just want my code to run
Как я могу уменьшить это дублирование?
Вещи, которые я пробовал:
autouse=True в conftest.py или в тестовый файл/класснапример
@pytest.fixture(autouse=True)
def patch_logger_add(monkeypatch):
monkeypatch.setattr("loguru.logger.add", lambda *args, **kwargs: None)
# or
# monkeypatch.setattr("loguru.logger.add", MagicMock())
или
@pytest.fixture(autouse=True)
def no_logger_add(monkeypatch):
monkeypatch.delattr("loguru.logger.add")
Это не работает. Возможно, потому, что для того, чтобы loguru работал с pytest, нам нужно переопределить caplog, а это включает в себя вызов logger.add.
Примечание. Я не хочу полностью отключать логуру, поскольку в своих тестах я проверяю журналы на наличие ошибок.
compute_statistics.py
from loguru import logger
class ExampleClass:
def compute(self):
logger.add("0_example.log")
logger.info("Starting to compute")
logger.success("Finished computing")
return "Done"
conftest.py
import pytest
from loguru import logger
from _pytest.logging import LogCaptureFixture
@pytest.fixture
def caplog(caplog: LogCaptureFixture):
handler_id = logger.add(
caplog.handler,
format = "{message}",
level=0,
filter=lambda record: record["level"].no >= caplog.handler.level,
enqueue=False, # Set to 'True' if your test is spawning child processes.
)
yield caplog
logger.remove(handler_id)
test_compute_statistics.py
import logging
import pytest
from compute_statistics import ExampleClass
from unittest.mock import patch
@pytest.fixture(autouse=True)
def patch_logger_add():
with patch("compute_statistics.logger.add"):
yield
def assert_no_errors_logged(caplog):
error_messages = [record for record in caplog.records if record.levelno >= logging.ERROR]
num_errors = len(error_messages)
assert num_errors == 0
def test_example_class(caplog):
ex = ExampleClass()
result = ex.compute()
assert result == "Done"
assert_no_errors_logged(caplog)






Поскольку вы говорите, что декоратор patch работает, а monkeypatch, похоже, нет, мне интересно, может ли использование patch в качестве контекстного менеджера из приспособления решить вашу проблему?
Пример
@pytest.fixture(autouse=True)
def patch_logger(caplog):
with patch("your_module.logger.add"):
yield
Это заставляет меня думать, что, возможно, patch_logger выполняется до переопределения caplog. Я обновил свой ответ, но можете ли вы попробовать указать caplog в качестве аргумента для patch_logger? Это должно обеспечить правильный порядок.
Все еще не работает, к сожалению. Я пробовал определить patch_loger сверху и снизу caplog в конфликте, но ничего не меняется. Кроме того, logger.add все еще выполняется (и файл журнала все еще создается), поэтому я не думаю, что autouse=True на самом деле его исправляет.
Порядок определений в файле конфликта не имеет значения. Pytest не может гарантировать порядок вызова фикстур, если мы не объединим их вместе, что мы и сделали, указав caplog в качестве аргумента. Это работает правильно в базовом примере, который я воссоздал на своем компьютере, и файл журнала никогда не создается.
Однако, поскольку файл все еще создается, я думаю, что patch неверен. Попробуйте исправить ситуацию, где logger импортируется и используется, а не определяется. Например your_module.logger.add
Я добавил минимальный воспроизводимый пример к вопросу, который не работает на моей машине. Можете ли вы попробовать это? Надеюсь, теперь вам очевидно, что происходит не так! Исправление compute_statistics.logger.add не помогло, не удалось удалить caplog, поскольку по какой-то причине оно исправляет logger.add внутри caplog приспособления.
Когда я запускаю пример, он не работает с обратной ссылкой logger.remove. Это связано с тем, что патч по-прежнему применяется во время удаления. В вашем примере отсутствует patch_logger_add(caplog), о котором я говорил ранее. Несмотря на то, что мы не используем caplog в этом приспособлении, предоставляя его в качестве аргумента, мы гарантируем, что патч будет применен после установки caplog и удален перед демонтажем.
Удивительный! Да, это сработало. Мне также пришлось изменить другую часть кода (не включенную в приведенный выше пример), что меня смутило. Спасибо за вашу помощь.
Это сработает, если я не пройду
caplogтесты. Но если я это сделаю, произойдет сбой при демонтаже. Мы переопределяемcaplogи он используетlogger.add, что ломает вещи