Здравствуйте, Y-Vladimir, Вы писали:

YV>Написание стабильных тестов — непростая задача. В особенности, если они будут интегрироваться в билд-сервер (в идеале на Continious Integration Build). Если не предпринимать специальных архитектурных решений, то тест будет частенько падать.

На самом деле архитектурные решения могут быть не такими уж и сложными (обычная Functional Decomposition ). Фактически есть несколько ключевых моментов, на которые обычно делается упор: синхронизация, параметризация, отделение движка от ресурсов. Всё остальное — по вкусу.

YV>В основном из-за того, что при использовании Record & Play не учитываются паузы между действиями — для автоматизации нетривиальных контролов нужно ставить нечто типа цикла ожидания для четкой фиксации какого-то события, окончания действия и т.д.

Есть ряд общих шаблонов решения данной проблемы. Часть из них описана здесь, ну и несколько более "кучерявый" случай здесь.

YV>Очень полезной практикой является запуск автотестов при каждой заливке девелоперами и рассылка письма на команду, если при очередном сабмите упал автотест — позволяет оперативно обнаруживать баги.

Кстати, поэтому я зачастую рекомендую использовать средства, которые наиболее близки к используемым средствам разработки, хотя бы в плане языка и IDE, так как они отлично вписываются в процесс автосборки ,плавно переходящий в автотестирование.

YV>Но по своему опыту могу сказать, что отладить и настроить такой процесс очень непросто

По своему опыту могу сказать, что привыкнуть к такому процессу крайне трудно, особенно, если он ставится не вначале разработки, а где-то на более поздних стадиях, когда уже много чего сделано. Я так собрал цепочку, которая автоматом вытягивает исходники тестов, запускает их и результаты постит в баг-трекер (одна ошибка — один дефект) с нотификацией. 450 дефектов после первого же запуска (часть из них цепные). Пару волн типа "запустил-собрал баги-пофиксил" и код резко стабилизировался. Но для такого напряга надо быть хоть немного морально готовым