Это, очевидно, немного основано на мнении, но я попробую.
Во-первых, нет ничего плохого в том, что тесты больше тестируемого кода. Это может легко произойти в зависимости от количества протестированных вариантов использования, и я бы не стал использовать этот критерий для качества теста.
При этом ваши тесты обычно должны тестировать API / интерфейс, который в этом случае является возвращаемым путем к файлу при других условиях. Проверка того, был ли вызван os.path.expanduser
, является частью внутренней реализации, которая может быть нестабильной - я не считаю это хорошей идеей, по крайней мере, в этом случае. Вы уже тестировали наиболее подходящие варианты использования (может быть добавлен тест на наличие файлов в обоих местах), где используются эти внутренние компоненты.
Вот что я, вероятно, сделал бы:
import os
import pytest
from cei import get_xls_filename
@pytest.fixture
def cwd(fs, monkeypatch):
fs.cwd = "/my/path"
monkeypatch.setenv("HOME", "/home/user")
def test_get_xls_filename_not_found(fs, cwd) -> None:
with pytest.raises(SystemExit):
assert get_xls_filename()
def test_get_xls_filename_current_folder(fs, cwd) -> None:
fs.create_file("/my/path/InfoCEI.xls")
assert get_xls_filename() == "InfoCEI.xls" # adapted to your implementation
def test_get_xls_filename_download_folder(fs, cwd) -> None:
path = os.path.join("/home/user", "Downloads", "InfoCEI.xls")
fs.create_file(path)
assert get_xls_filename() == path
Обратите внимание, что я использовал приспособление pyfakefs fs
, чтобы высмеивать fs (я являюсь участником pyfakefs, так что это то, к чему я привык, и это делает код немного короче), но это может быть излишним для вы.
По сути, я пытаюсь протестировать только API, помещаю общую настройку (здесь cwd и местоположение домашнего пути) в прибор (или в метод настройки для тестов, подобных xUnit), и добавляю спецификацию теста c настройка (создание файла теста) для самого теста.