t.me/atinfo_chat Telegram группа по автоматизации тестирования

один тест с длинным флоу vs несколько декомпозированных зависимых тестов


(gam) #1

Часто возникает проблема выбора. Как лучше организовать свои тесты когда необходимо покрыть большой сценарий?


(Taras) #2

Page Object Pattern , проблема уже обговаривалась на форуме) Ищите в поиске по словам. Нужно писать качественный фреймворк, так как в больших сценариях соответсвенно будет большое количество и локаторов и тестов итд, и все взаимосвязано. Так одно изминение может изменить функционал еще в некоторых и местах и при етом не удобно будет переписывать тесты. По этому писать нужно структурованно.


(Mykhailo Poliarush) #3

и "один тест с длинным флоу" и "несколько декомпозированных зависимы" не сильно хорошо.

"один тест с длинным флоу" - плох тем, что когда сламается что-то в начале флова, то сцпенарий будет ждать когда баг пофикситься, но за багом может скриываться другой баг и это вы обнаружите только тогда, когда первый баг пофикситься. Также такие сценарий очень долго выполняются и есть большая вероятность того, что они будут подать по причине тайм аутов или каких либо еще зависимых причин. 

"несколько декомпозированных зависимы" - плохо тем, что тесты зависимые, честно говоря в данном случае этот вариант не сильно отличается от первого, т.е. если первый тест упадет, который должен был создать что-то для вас, то второй даже если и стартанет, но при этом не дойдет до конца потому что у него не будет начальных данных.

тут правильно было бы разбить тесты на уровни, интеграционные, апи, и дальше тогда можете делать тесты с длинным флов, потому что предыдущие уровне должны выявить грубые ошибки, а один длинный флов, проверить целостную картину.


(Mykhailo Poliarush) #4

веб? десктоп? серверная? 


(gam) #5

Апликейшн - веб на гвт. фрейверк - елемент обджект, java + web driver. 

Есть юнит и интеграционные тесты. Автоматизация направлена сугубо на функциональное тестирование в регрессионных целях. Основная цель - покрыть аксептанс критерии, которые, как вы понимаете могут затрагивать много всего.  Как правило, тесты создаются среднего размера без зависимостей.  

Из плюсов маленьких тестов вижу более простую поддержку. С маленьким куском кода всегда проще разобраться чем с большим. А зависимости можно настроить так, чтобы при одном фейле, цепь дальше не выполнялась.

 


(Mykhailo Poliarush) #6

>>Как правило, тесты создаются среднего размера без зависимостей.

так если у вас большинство, таких тестов и есть уровне автоматизации, так в чем же тогда вопрос?

имхо, если юнит и интеграционные тесты работают хорошо и выполняются постоянно, так чтобы им можно было доверять, то тогда можно использовать большие тесты с описанием полного флов. Только перед запуском этих тестов вам нужно проганять ваши юнит и интеграционные тесты и они все должны быть зелеными.


(gam) #7

>>>>Как правило, тесты создаются среднего размера без зависимостей.

>>так если у вас большинство, таких тестов и есть уровне автоматизации, так в чем же тогда вопрос?

Стартовал новый проект, хочется убрать пробелы и улучшить процесс автоматизации.

>> Только перед запуском этих тестов вам нужно проганять ваши юнит и интеграционные тесты и они все должны быть зелеными.

юнит и интегрейшены крутятся при каждой сборке.

Как показывает практика, даже среднего размера тесты, неговоря уже о больших, запутанны и тяжелы в поддержке, обеспечивают меньшую прозрачность резалт ранов - нельзя быстро определить в каком месте функционала проблема.

Подозреваю зависимости решат мою проблему. Но много раз слышал, что зависимые тесты это плохо.  Так в чем собственно это плохо? (помимо вышеперечисленного вами)

 


(KaNoN) #8

Если у вас даже среднего размера тесты запутаны и тяжелы в поддержке, то наделав много зависимостей вы только уходшите ситуацию, так как помимо локализации места ошибки вам еще предстоит выявить всю последовательность тестов. К тому же появляется дополнительная проблема, особенно характерная для движков семейтва xUnit и подобных им. Эти движки в общем случае не гарантируют определеннный порядок выполнения тестов. Соответственно, вам надо будет еще определить, все ли необходимые тесты отработали и если нет, то придется настраивать зависимости. 

Если появляется сложность в понимании и поддержке тестов, то скорее всего имеет смысл посмотреть в сторону качества кода. Например, обратить внимание на четкое разделение между бизнес-функционалом и отдельным специфичным воркфлоу. За счет высокого переиспользования кода можно и ускорить процесс написания тестов и их поддержку.

Также, например, желательно, чтобы в самом тестовом методе уже не присутствовали явные определения локаторов или других идентификаторов оконных объектов. Пусть лучше они будут обернуты внутри некоторой бизнес-функции, которая и будет вызываться непосредственно из теста. Как минимум, это повышает читаемость кода.

Это только некоторые из практик. В-общем, подумайте, что не так в самом дизайне автотестов и их реализации. Проблемы скорее всего там.


(Mykhailo Poliarush) #9

так вот, надо сначала понять цель и что нужно улучшить, а потом уже решать что делать

воспользуйтесь техникой "5 whys?" и опредилите истиную причину, которую вы хотите решить

и дальше нужно уже будет от этого от талкиваться, потому что мои и других советы не будут для вас полезные без контекста проблемы и цели которую нужно решить