Блок 2 · Урок 4 из 4 · ≈ 9 минут · цель: проверять поведение без привязки к реализации
Интерфейс как поверхность тестов
Interface as a test surface
Главная мысль: тесты должны защищать обещание интерфейса, а не замораживать внутренние шаги реализации.
Тестируем: наблюдаемое поведение.
Не закрепляем: внутренний порядок шагов без нужды.
Зачем это вам
Когда агент меняет код, тесты становятся договором: что нельзя сломать. Если тесты проверяют внутренние детали, агенту трудно улучшать реализацию. Если тесты проверяют публичное поведение, модуль можно углублять безопаснее.
Это особенно важно для рефакторинга: цель не в том, чтобы “код выглядел иначе”, а в том, чтобы внешнее обещание осталось тем же при более простой внутренней структуре.
Суть
Поведенческий тест проверяет, что пользователь модуля получает правильный результат через публичный интерфейс.
Хрупкий тест закрепляет детали реализации: какие приватные функции вызвались, в каком порядке прошли внутренние шаги, как названы временные переменные.
Перед задачей агенту полезно назвать тестовую поверхность: какой публичный вызов, компонент или сценарий должен подтвердить поведение.
Аналогия
Когда вы проверяете чайник, вы не обязаны знать, как внутри сработал нагреватель. Вам важно, что после понятного действия вода нагрелась, чайник отключился и не протек.
Запомните одно
Тест через интерфейс дает свободу менять реализацию. Тест внутренних шагов часто превращает реализацию в часть внешнего контракта.
Фраза агента → что он имеет в виду
- «Добавлю acceptance test»
- Проверка будет смотреть на пользовательский или публичный сценарий, а не на внутренние детали.
- «Не буду мокать приватную функцию»
- Агент пытается оставить внутреннюю реализацию свободной для будущих изменений.
- «Какой public API считать стабильным?»
- Нужно назвать поверхность, поведение которой тесты должны защищать.
Мини-словарь
- Public behavior
- Публичное поведение: результат, видимый через интерфейс модуля.
- Acceptance test
- Проверка, подтверждающая, что обещанное поведение выполнено.
Проверьте себя
Какой тест лучше поддерживает глубокий модуль?
Да: тест через интерфейс защищает обещание модуля и оставляет реализацию гибкой.
Связанные материалы
Основной источник
- Stanford CS190: Modular Design, John Ousterhout.
- A Philosophy of Software Design, John Ousterhout.