Функция-заглушка

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

function ReadThermometer(Source source)
    return 28
end function

Пример реализации функции-заглушки на TypeScript для имитации асинхронного вызова API с использованием Promise и setTimeout^[5]:

function getMockData(): Promise<{ type: string; data: string }> {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve({
        type: 'Success',
        data: 'mocked data',
      });
    }, 1000);
  });
}

Пример использования Microsoft Fakes (C#) для создания заглушки интерфейса и переопределения возвращаемого значения^[6][7]:

IDataProvider fakeProvider = new FakesBasics.Fakes.StubIDataProvider()
{
    GetPersonInt32 = (id) => 
    { 
        return new Person() { Id = id, FirstName = "John", LastName = "First" }; 
    }
};

В контексте разработки API главное отличие функции-заглушки (Stub) от мок-объекта (Mock) заключается в том, что заглушка фокусируется на возвращаемом состоянии (предоставляя заранее заданные ответы), тогда как мок-объект — на проверке поведения и взаимодействия^[2][8].

В современном тестировании ключевые принципы использования заглушек (API stubbing) включают изоляцию тестов от нестабильных внешних зависимостей, детерминированную валидацию (проверку обработки ошибок и преобразований данных в предсказуемых условиях) и опережающее тестирование, позволяющее проверять поведение клиента до полной готовности реальных сервисов^[15].

В микросервисной архитектуре заглушки обеспечивают изоляцию компонентов и независимую работу команд^[16]. Использование заглушек на основе общих контрактов взаимодействия (например, OpenAPI для REST или .proto-файлов для gRPC) позволяет вести параллельную разработку. Подход Contract-First даёт возможность автоматически генерировать заглушки, тестировать клиентские части без готового бэкенда и снижает риск несовместимости при интеграции^[17].^[18]

Создание функций-заглушек и базовых тестовых наборов активно автоматизируется с помощью ИИ-ассистентов, берущих на себя рутинные задачи по генерации моков и тестовых данных. Это влияет на методологию разработки через тестирование (TDD), которая становится критически важным слоем проверки. Разработчик концентрируется на проектировании поведения и фиксации спецификаций в виде тестов до написания кода, делегируя ИИ механическую реализацию^[19].^[20]