Тестирование файловой персистентности

Question

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

public interface IFilePersist
{
   void Save(XXX, FileLocation);
}

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

Это накладные расходы? Эта практика широко используется? Для операций, связанных с БД, этот вид операции тривиален и всегда используется.

Answer 1

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

Реальная стойкость файловой системы должна быть проверена с помощью интеграционных тестов.

Answer 2

Да, это один из способов сделать это, если вы хотите сократить накладные расходы на создание фиктивного объекта отслеживания, вы можете также сделать локальное переопределение метода, если это возможно. Я не знаю, какой язык вы используете, но в Java локальное переопределение будет выглядеть так:

// actual class
public class SomeClass {
    public void method() {
        System.out.println("Hello!");
    }
}

// creating the class in test

SomeClass c = new SomeClass() {
public void method() {
        System.out.println("Hi!");
    }       
};

Теперь ваш класс печатает "Привет!" когда вызывается m (), потому что он переопределяется в анонимном внутреннем классе, в то время как фактический производственный класс продолжает печатать «Hello!».