Эмулирующая / фальсифицирующая файловая система для тестирования кода на C? - PullRequest
4 голосов
/ 07 июля 2010

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

Так что я думаю о замене реального доступа к файловой системе специальнымэмулятор файловой системы.Таким образом, каждый тест, требующий доступа к файловой системе, может создавать новый экземпляр виртуального объекта файловой системы, и я могу запускать тесты изолированно и надлежащим образом поддерживать тестирование в Windows., но до сих пор не найдено ни одного для C кода.Любые советы?

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

Ответы [ 3 ]

4 голосов
/ 07 июля 2010

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

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

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

1 голос
/ 07 июля 2010

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

1 голос
/ 07 июля 2010

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

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

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

...