Отправлено 12 августа 2016 - 13:01
Чтобы избежать подобных влияний, да и вообще погрешностей замеров и ложных срабатываний, прогоняйте один и тот же тест несколько раз с исходными н.у.
ну flacky -тесты еще никто не отменял, т.е. да можно уменьшить число "ложных срабатываний", там увеличить время ожидания, улучшить локаторы. Но полностью избавиться нереально.
Правильно ли я понимаю, что в таком случае технология такая. Мы сегодня запускаем несколько сотен тестов, завтра обнаруживаем, что несколько десятков не сработало, и заново запускаем этот десяток. И так пока не обнаружим, что какой-то тест устойчиво не проходит. И тогда уже начинаем детально разбираться - почему.
Так?
обнаруживаем, что не сработало несколько десятков, а другим десяткам повезло и в следующий раз они полетят) так и будете играть в рулетку. Лучше как предложил BabyRoot. К-но, тесты у вас д.б. независимы) и с хорошей архитектурой, чего трудно добиться в условиях ограниченного времени. Даже труднее чем написание самого теста. Но реально, если выделяются под это ресурсы, не на 100% к-но. Удачи!
"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс