Несколько слов о дизайне автоматических тестов.
Точнее о вопросе избыточности проверок. Существует подход к разработке модульных (Unit) автоматических тестов, который можно описать так "Проверяем одно условие за один тест" (Verify one condition per test). Применение такой стратегии дает множество плюсов: при провале тестов можно максимально быстро выявить узкое место, и, как следствие, максимально быстро устранить проблему. Пусть тестов станет больше, но плюсы, как правило перевешивают.
При автоматизации более громоздких регрессионных функциональных тестов подобная стратегия также применима. Только в роли единицы проверки должны выступать уже не "условия" , а конкретный вариант поведения. При этом, все что лишнее, и не влияющее на данный конкретный вариант поведения должно быть безжалостно ампутировано. Лишними могут быть: некоторые инициализирующие параметры объектов, а также проверки , которые уже делались или будут делаться в тестах, специально для этого предназначенных. В общем, не надо делать лишних движений, у которых нет конкретных целей.
Вот пример из реальной практике, иллюстрирующий вышесказанное:
1. есть автоматический функциональный тест, проверяющий некий вариант поведения системы
2. в ходе его инициализации создается объект "клиент", у которого есть как обязательные так и необязательные параметры, причем данному тесту ни один из них не важен - важен факт наличия объекта "клиент" и все..
3. тестировщик, который создавал тест, то ли копипастом, то ли для разнообразия решил заполнить поле email , причем указал там строку с емейлом "не по RFC" (на момент написания теста проверке необязательного email внимания не уделялось)
4. тест долгое время работал, проверял нужные варианты, давал результат
5. в какой-то момент проверке полей данного объекта уделили внимание, и ужесточили ее, создав соответствующие автотесты на эту новую "функциональность"
6. старый же тест начал проваливаться, причем, не доходя до своей целевой проверки - проваливаться на этапе инициализации. Причина, думаю, ясна - строка "отбалды" в поле email.
Тест пришлось править, тратить время. Пусть не много времени ушло данный конкретный тест, но в принципе - это лишняя трата времени, лишнее отвлечение внимания на провал теста. Причина - "лишние движения" и никому ненужная "кучерявость" теста. Всему свое место - фантазии и творчеству, в том числе :)
Вывод: чуть больше осознанности может сэкономить чуть больше времени для чуть более полезных вещей :)
Хороший дизайн автоматического теста вообще и фрейма вчастности может сильно сэкономить время. Отсутствие избыточных проверок, хорошие оракулы, хорошее логирование. Это спасает.
ОтветитьУдалитьС другой стороны надо мыслить шире простых скриптовых тестов на проверку регрессий через, скажем, GUI и использовать возможности автоматизации на полную катушку. Делать, например, вот так:
http://angryweasel.com/blog/?p=342