Как тестируют в Google - стр. 39
Разработчик в тестировании тщательно анализирует protobuf-код, потому что вскоре ему придется реализовывать большинство интерфейсов и протоколов, описанных в этом коде. Все верно, именно разработчик в тестировании обычно делает эту работу. Необходимость в интеграционном тестировании часто возникает до того, как будут построены все зависимые подсистемы, и к этому надо быть готовым. Чтобы проводить интеграционное тестирование настолько рано, разработчик в тестировании создает имитации и заглушки нужных зависимостей каждого компонента. Интеграционные тесты все равно придется написать, и чем раньше они будут написаны, тем больше от них пользы. Подставные объекты и имитации пригодятся для интеграционного тестирования и дальше. Через них гораздо проще имитировать условия возникновения ошибки и сам сбой, чем через боевую систему.
На заметку
Чтобы проводить интеграционное тестирование как можно раньше, разработчик в тестировании создает имитации и заглушки нужных зависимостей каждого компонента.
Планирование автоматизации
Время разработчика в тестировании ограничено и расписано по минутам, поэтому хорошая идея – создавать план автоматизации как можно раньше. План должен быть реалистичным. Пытаться автоматизировать все сразу в одном тестовом пакете – это ошибка. У разработчиков такие наполеоновские планы обычно не вызывают восторга, и они не спешат помогать. Если разработчик в тестировании хочет заручиться поддержкой разработчика, план автоматизации должен быть простым, четким и способным повлиять на проект. Тяжело поддерживать масштабную автоматизацию, которая с ростом системы расшатывается еще больше. Разработчиков можно привлечь писать только узконаправленные автотесты, которые приносят пользу с самого начала.
Не стоит слишком рано вкладываться в сквозную автоматизацию – она привязывает вас к конкретной архитектуре проекта и не имеет смысла, пока продукт не сформировался и не стал стабильным. Если вы начали слишком рано и собрали много информации, она все равно обесценится к концу проекта, потому что уже поздно будет менять архитектуру продукта. Время, которое разработчик в тестировании мог бы уделить шлифовке качества, было потрачено на сопровождение неустойчивых сквозных тестов.
На заметку
Не стоит слишком рано вкладываться в сквозную автоматизацию – она привязывает вас к конкретной архитектуре проекта.
В Google разработчики в тестировании подходят к планированию так. Сначала мы выделяем интерфейсы, которые, как нам кажется, могут содержать баги. Мы создаем подставные объекты и имитации, чтобы контролировать взаимодействие с этими интерфейсами и обеспечить хорошее тестовое покрытие.