Блог

Я ищу кроссплатформенный способ протестировать некоторые функции моего приложения, для которых требовался доступ к файловой системе (для записи и чтения двоичных данных). В реальной жизни мое приложение работает на Linux и хранит специальные данные в /usr/local/etc каталоге. Но основная часть приложения — это кроссплатформенная библиотека, и ее следует тестировать как на Windows, так и на Linux. Кроме того, я не хочу, чтобы мои тесты записывали / считывали данные напрямую в /usr/local/etc , потому что в этом случае это нарушит изоляцию теста.

Итак, я подумываю о замене реального доступа к файловой системе специальным эмулятором файловой системы. Таким образом, каждый тест, который требовал доступа к файловой системе, может создавать новый экземпляр объекта vistual filesystem, и я могу запускать тесты изолированно и должным образом поддерживать тестирование в Windows.

Я пытался найти какую-нибудь существующую открытую / бесплатную реализацию, но пока не нашел ни одной для кода на C. Есть какие-нибудь подсказки?

ОБНОВЛЕНИЕ: решения только для Linux с chroot для меня не подходят.

Я бы сделал расположение файловой системы настраиваемым — либо с помощью опции командной строки, либо с помощью переменной окружения (оба они одинаково хорошо работают с Linux и Windows).

По умолчанию может быть /usr/local/etc/ , но для тестирования (или в Windows) вы можете указать другое местоположение. Если вы запускаете несколько команд, то метод переменной среды работает особенно хорошо, поскольку вы можете задать переменную один раз, а затем просто запускать команды так же, как они выполнялись бы, если бы они использовали хранилище по умолчанию.

Для обоих методов стоит подумать, есть ли какие-либо последствия для безопасности при настройке местоположения — обычно их не будет (исполняемый файл сможет делать только то, что пользователь мог бы уже сделать), но если вы используете исполняемый setuid, вам может потребоваться больше размышлений.

В Linux вы можете проделать fakeroot трюк: LD_PRELOAD создать библиотеку, которая перехватывает open , read и write вызовы и перенаправляет их на то, что вы хотите сделать. Я не знаю, есть ли эквивалентный способ внедрить код таким образом в двоичный файл Windows.

chroot есть еще один способ предоставить тестируемой программе собственную иерархию fs. Вы также можете попробовать написать свои собственные заглушки libc для fopen и friends и связать эту библиотеку с вашей тестовой программой, но это не будет перехватывать вызовы, выполняемые другими библиотеками.

Другим подходом может быть уровень абстракции ввода-вывода, такой как openssl BIO, где вызовы ввода-вывода могут быть легко перехвачены путем замены библиотеки абстракций.

Как насчет тестирования в qemu и запуска каждого запуска с одним и тем же предварительно созданным образом файловой системы?