PHP: Продвинутое тестирование
2026-02-26 16:52 Diff
https://ru.hexlet.io/courses/php-advanced-testing/lessons/files/theory_unit

Наиболее типичный побочный эффект – взаимодействие с файлами (файловые операции). В основном это либо чтение файлов, либо запись в них. С чтением разбираться значительно проще, поэтому с него и начнём.

Чтение файлов

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

При тестировании функций, читающих файлы, должно выполняться ровно одно условие. Функция должна позволять менять путь до файла. В таком случае, достаточно создать файл нужной структуры в фикстурах.

В тестах читать /etc/passwd (файл содержащий список пользователей системы в Linux) нельзя, потому что содержимое этого файла зависит от окружения, в котором запущены тесты. Для тестирования нужно создать файл аналогичной структуры в фикстурах и указать его при запуске функции:

Запись файлов

С записью файлов уже сложнее. Главная проблема – отсутствие гарантированной идемпотентности. Это значит, что повторный вызов функции, записывающей файлы, может вести себя не как первый вызов, например, завершаться с ошибкой, либо приводить к другим результатам.

Почему? Представьте себе, что мы пишем тесты на метод log($message), который дописывает все переданные в него сообщения в файл:

Это значит, что каждый запуск тестов будет немного другим. При первом запуске тестов создается файл для хранения логов. Затем он начнёт заполняться. Это приводит к целой пачке проблем:

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

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

В большинстве ситуаций такое решение работает нормально, но всё же не во всех. Выполнение кода тестов — это не атомарная операция. Нет никакой гарантии, что хук tearDown() выполнится. Есть много причин, по которым этого может не произойти, начиная от внезапного отключения электроэнергии, заканчивая ошибками в самом PHPUnit.

Есть только один надёжный способ делать очистку – делать это до теста, а не после, в setUp(). С таким подходом есть только одна небольшая сложность. При первом запуске тестов файла нет. Это значит, что прямой вызов unlink() завершится с ошибкой и тесты не смогут выполниться. Чтобы избежать этого, можно ввести проверку:

Другой вопрос при записи файлов. Куда их сохранять? Однозначно избегайте записи файлов прямо внутри проекта. Если тестируемый код позволяет сконфигурировать место записи, то используйте системную временную директорию. Её можно получить с помощью функции: sys_get_temp_dir()

Виртуальная файловая система (ФС)

Это ещё один способ тестировать код, работающий с ФС. С помощью специальной библиотеки во время тестов создается виртуальная файловая система. Она автоматически подменяет реальную файловую систему. Это значит, что функцию, которая тестируется, трогать не надо. Эта функция продолжает думать, что она работает с реальным диском. Вся конфигурация при этом задаётся снаружи:

Этот способ даёт идемпотентность из коробки. Вызов функции vfsStream::setup() формирует окружение на каждый запуск с нуля. То есть достаточно добавить её в setUp() и можно приступать к тестированию.