testomat.io управление авто тестамиЧасто возникает проблема выбора. Как лучше организовать свои тесты когда необходимо покрыть большой сценарий?
Page Object Pattern , проблема уже обговаривалась на форуме) Ищите в поиске по словам. Нужно писать качественный фреймворк, так как в больших сценариях соответсвенно будет большое количество и локаторов и тестов итд, и все взаимосвязано. Так одно изминение может изменить функционал еще в некоторых и местах и при етом не удобно будет переписывать тесты. По этому писать нужно структурованно.
и "один тест с длинным флоу" и "несколько декомпозированных зависимы" не сильно хорошо.
"один тест с длинным флоу" - плох тем, что когда сламается что-то в начале флова, то сцпенарий будет ждать когда баг пофикситься, но за багом может скриываться другой баг и это вы обнаружите только тогда, когда первый баг пофикситься. Также такие сценарий очень долго выполняются и есть большая вероятность того, что они будут подать по причине тайм аутов или каких либо еще зависимых причин.
"несколько декомпозированных зависимы" - плохо тем, что тесты зависимые, честно говоря в данном случае этот вариант не сильно отличается от первого, т.е. если первый тест упадет, который должен был создать что-то для вас, то второй даже если и стартанет, но при этом не дойдет до конца потому что у него не будет начальных данных.
тут правильно было бы разбить тесты на уровни, интеграционные, апи, и дальше тогда можете делать тесты с длинным флов, потому что предыдущие уровне должны выявить грубые ошибки, а один длинный флов, проверить целостную картину.
веб? десктоп? серверная?
Апликейшн - веб на гвт. фрейверк - елемент обджект, java + web driver.
Есть юнит и интеграционные тесты. Автоматизация направлена сугубо на функциональное тестирование в регрессионных целях. Основная цель - покрыть аксептанс критерии, которые, как вы понимаете могут затрагивать много всего. Как правило, тесты создаются среднего размера без зависимостей.
Из плюсов маленьких тестов вижу более простую поддержку. С маленьким куском кода всегда проще разобраться чем с большим. А зависимости можно настроить так, чтобы при одном фейле, цепь дальше не выполнялась.
>>Как правило, тесты создаются среднего размера без зависимостей.
так если у вас большинство, таких тестов и есть уровне автоматизации, так в чем же тогда вопрос?
имхо, если юнит и интеграционные тесты работают хорошо и выполняются постоянно, так чтобы им можно было доверять, то тогда можно использовать большие тесты с описанием полного флов. Только перед запуском этих тестов вам нужно проганять ваши юнит и интеграционные тесты и они все должны быть зелеными.
>>>>Как правило, тесты создаются среднего размера без зависимостей.
>>так если у вас большинство, таких тестов и есть уровне автоматизации, так в чем же тогда вопрос?
Стартовал новый проект, хочется убрать пробелы и улучшить процесс автоматизации.
>> Только перед запуском этих тестов вам нужно проганять ваши юнит и интеграционные тесты и они все должны быть зелеными.
юнит и интегрейшены крутятся при каждой сборке.
Как показывает практика, даже среднего размера тесты, неговоря уже о больших, запутанны и тяжелы в поддержке, обеспечивают меньшую прозрачность резалт ранов - нельзя быстро определить в каком месте функционала проблема.
Подозреваю зависимости решат мою проблему. Но много раз слышал, что зависимые тесты это плохо. Так в чем собственно это плохо? (помимо вышеперечисленного вами)
Если у вас даже среднего размера тесты запутаны и тяжелы в поддержке, то наделав много зависимостей вы только уходшите ситуацию, так как помимо локализации места ошибки вам еще предстоит выявить всю последовательность тестов. К тому же появляется дополнительная проблема, особенно характерная для движков семейтва xUnit и подобных им. Эти движки в общем случае не гарантируют определеннный порядок выполнения тестов. Соответственно, вам надо будет еще определить, все ли необходимые тесты отработали и если нет, то придется настраивать зависимости.
Если появляется сложность в понимании и поддержке тестов, то скорее всего имеет смысл посмотреть в сторону качества кода. Например, обратить внимание на четкое разделение между бизнес-функционалом и отдельным специфичным воркфлоу. За счет высокого переиспользования кода можно и ускорить процесс написания тестов и их поддержку.
Также, например, желательно, чтобы в самом тестовом методе уже не присутствовали явные определения локаторов или других идентификаторов оконных объектов. Пусть лучше они будут обернуты внутри некоторой бизнес-функции, которая и будет вызываться непосредственно из теста. Как минимум, это повышает читаемость кода.
Это только некоторые из практик. В-общем, подумайте, что не так в самом дизайне автотестов и их реализации. Проблемы скорее всего там.
так вот, надо сначала понять цель и что нужно улучшить, а потом уже решать что делать
воспользуйтесь техникой "5 whys?" и опредилите истиную причину, которую вы хотите решить
и дальше нужно уже будет от этого от талкиваться, потому что мои и других советы не будут для вас полезные без контекста проблемы и цели которую нужно решить