Тестирование до и после фиксации
Итак, какие тесты следует выполнять перед фиксацией? Мы следуем общему правилу: только быстрые и надежные. На этапе тестирования перед фиксацией можно пожертвовать некоторой полнотой охвата, но это означает, что вы должны выявить любые оставшиеся проблемы на следующем этапе тестирования после фиксации и быть готовыми выполнить некоторое количество откатов. После фиксации можно позволить себе потратить больше времени на борьбу с нестабильностью, если для этого есть надлежащие механизмы.
В разделе «Непрерывная интеграция в Google» мы увидим, как TAP осуществляет управление сбоями.
Мы не хотим жертвовать продуктивностью инженеров, поэтому на этапе предварительной проверки выполняем только тесты для проекта, в котором происходят изменения. Мы также выполняем тесты параллельно, поэтому учитываем затраты вычислительных ресурсов. Наконец, мы не хотим выполнять ненадежные тесты на этапе предварительной проверки, потому что слишком высока стоимость привлечения инженеров к устранению проблемы, которая не связана с изменениями.
На этапе предварительной проверки большинство команд в Google выполняют свои маленькие тесты (например, юнит-тесты)224, которые, как правило, самые быстрые и надежные. Но есть ли смысл выполнять тесты с широким охватом перед фиксацией? Ответ на этот вопрос зависит от команды. Команды, считающие нужным их выполнять, используют проверенный подход герметичного тестирования, помогающий уменьшить нестабильность, свойственную таким тестам. Другой возможный подход: выполнять ненадежные тесты с широким охватом при предварительной проверке, но отключать их, когда они начинают терпеть неудачу.
Итак, какие тесты следует выполнять перед фиксацией? Мы следуем общему правилу: только быстрые и надежные. На этапе тестирования перед фиксацией можно пожертвовать некоторой полнотой охвата, но это означает, что вы должны выявить любые оставшиеся проблемы на следующем этапе тестирования после фиксации и быть готовыми выполнить некоторое количество откатов. После фиксации можно позволить себе потратить больше времени на борьбу с нестабильностью, если для этого есть надлежащие механизмы.
В разделе «Непрерывная интеграция в Google» мы увидим, как TAP осуществляет управление сбоями.
Мы не хотим жертвовать продуктивностью инженеров, поэтому на этапе предварительной проверки выполняем только тесты для проекта, в котором происходят изменения. Мы также выполняем тесты параллельно, поэтому учитываем затраты вычислительных ресурсов. Наконец, мы не хотим выполнять ненадежные тесты на этапе предварительной проверки, потому что слишком высока стоимость привлечения инженеров к устранению проблемы, которая не связана с изменениями.
На этапе предварительной проверки большинство команд в Google выполняют свои маленькие тесты (например, юнит-тесты)224, которые, как правило, самые быстрые и надежные. Но есть ли смысл выполнять тесты с широким охватом перед фиксацией? Ответ на этот вопрос зависит от команды. Команды, считающие нужным их выполнять, используют проверенный подход герметичного тестирования, помогающий уменьшить нестабильность, свойственную таким тестам. Другой возможный подход: выполнять ненадежные тесты с широким охватом при предварительной проверке, но отключать их, когда они начинают терпеть неудачу.
