testomat.io управление авто тестамиУ меня такой не обычный вопрос. В компании есть тесты под web приложение. Также приложение можно открыть под mobile и tablet разрешением экрана( соответственно дизайн приложения меняется под каждое разрешение экрана). Руководство ставит задачу, что надо
писать тесты под mobile и tablet. Вопрос: какие подходы существуют что бы в этом же framework без громадного изменения кода написать тесты под mobile и tablet view ports? Я понимаю что придется писать много if else statements. Может кто то с этим сталкивался и есть какой то проверенный подход как лучше сделать. Заранее спасибо
По-своему скромному опыту и положению дел на таком же if-then проекте советую не делать так. Вы будете платить за незначительное преимущество в переиспользовании части кода добавочной сложностью. И как вы будете обходить ситуации, если одна из версий будет отставать по доработкам от другой? Там же не только размеры меняются? Скорее всего и функционал между версиями не тождествен.
2 лайка
У вас же веб - зачем if-else?
щас никаких if-else нет. если будет ‘mobile and tablet’ то придется писать if-else, либо писать отдельные тесты под каждую платформу ‘mobile’ and ‘tablet’. Вот и думаем как оптимальнее будет всего это сделать с меньшим переписыванием кода
У вас сейчас адаптивный дизайн или вообще разные веб-приложения для мобайл и десктопа?
Илья, на этом форуме телепатов нет. Из описания вашей проблемы нет никакой конкретики. Если тесты одинаковые на 100% и отличие лишь в размерах элементов (что вряд ли), то что мешает их сейчас запускать на другой версии сайта? Почему не думаете в сторону DataProvider’а? Это всяко лучше чем пихать везде if-then, да и вместо if можно использовать функцию. В любом случае if’ы ухудшают структуру тестов. Как вы запускаете свои тесты? Используете ли CI? Бьете ли тесты на категори (комплекты)? Если вас попросят запустить только тесты для мобильной версии или все тесты или только для нового функционала вы сможете это сделать и за счет какого механизма? И опять-таки не решен вопрос «разъехавшихся» сайтов, когда одна из команд отстает от другой. Как будете следить за этим? Допускать красные тесты или как? Я это пишу потому что у меня есть пример перед глазами как не нужно было делать…
И еще один плюс в пользу отдельных тестов, если не используется DataProvider, это то, что разработка новых тестов идет более прозрачно для всех участников процесса. А иначе может возникнуть ситуация типа такой, что люди будут уверены, что там всего-то в паре мест поставить if и все займет пару часов. У меня примерно такая история и приключилась, при том что там нового кода на несколько десятков тысяч строк уже написано. Такая вот себе задачка на «два часа».
Я бы сказал дизайн отличается web vs mobile, tablet как 50% vs 50%. Можно посмотреть тут если интересно https://cooking.nytimes.com
Спасибо за развертанный ответ. У нас все бегает на CI (jenkins) + saucelab. Используем webdriverIO tool для автоматизации. Dataprovider не используем т.к. не вижу смысла в нем - мы никакие данные особо не вставляем в приложение. Механизм запуска тестов например если надо под web или мобайл отлажено, в этом проблемы нет. Все тесты разделены by features( запуск тестов для разных features тожет есть). Проблема только в одном, сайты ‘разъехавшие’ друг от друга примерно на 50%. После недели добавления в тесты if-else пришел к выводу ,что наверное придется некоторые существующие тесты изменять с if else. А тот функционал который присущ только mobile придется добавлять новые тесты под это. Незнаю что из этого получится в дальнейшим…
Я не вижу никакого различия ни в дизайне ни в функционале. Все “шероховатости” должны легко “разруливаться” через интерфейсы и наследование.
1 лайк