Какой должна быть идеальная структура проекта автотестов?

общие вопросы
, , , , , ,
#41

Вот один step - When (текст шага придумал сейчас):

    this.When('Кликаю на, допустим, кнопку "$visibleText"', function(visibleText) {
        var By = this.webdriver.By;
        var driver = this.driver;
        var locator;

        locator = By.xpath(".//*[@id='searchForm']/div[contains(., '" + visibleText + "')]");

        return this.waitFor(locator)
            .then(function(element) {
                return element.click()
            }.bind(this))
    });

сам waitFor:

    function waitFor(locator, waitTimeout) {
        waitTimeout = waitTimeout || 30000;
        var driver = this.driver;
        return driver.wait(function() {
            return driver.findElements(locator)
                .then(function(results) {
                    return results[0];
                });
        }, waitTimeout, "error timeout");
    }

Тест может быть кривым, учусь еще ). После питона.

1 лайк
#42

Боже какая красота :slight_smile: А зачем с питона спрыгнули то?

#43

А разве автотест не должен проделывать все теже самы действия, что и пользователь? Скажем если к 25-ому окну можно добраться через 25, по определенным кейсам, то тест и должен все это проходить, а не вызывать его, что проверить… Если же конечно его можно вызвать и без прохождения шагов (пользователь это может сделать по бизнес логике какой-то там, то и фреймворк должен уметь открывать данное окно откуда угодно)

#44

Не понимаю вопрос, но да, в тесте так и делаеться. Что вы имели ввиду?

#45

Ссори, не так понял, думал вы как раз имели ввиду, что не надо проходить кучу этих сценариев, а стоит сразу открыть каким-то образом окно :slight_smile:

Тема затянулась… Интересно все же как у людей реализовуются фреймворки :slight_smile:

#46

Все сценарии проходяться, но у нас было и есть так как я написал в примере: через invoke() метод страниц.

#47

Чтобы тема стала “горячей” достаточно произнести магические слова “идеальная структура” на техническом форуме. :smile:

4 лайка
#48

Идеальной структуры не существует. )

#49

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

#50

Смотря что тестируем. Со стороны пользователя это только один из вариантов.

#51

ТС, вместо промежуточных классов тестов стоит просто использовать хелперы.

#52

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

#53

Недавно смотрел презентацию товарища @asolntsev, где он упоминал идею фастлогина и подобных быстрых переходов на нужную страницу. Похожий подход используют в компании badoo и называют его QaAPI.
Идея очень понравилась) Жаль, что в проекте который сейчас хотим автоматизировать, данного API нет, однако модальных окон последовательно вытекающих один из другого немеренно… Уже “предвкушаю” эти долгие часы прохождения тестов.

1 лайк
#54

А с чего вы взяли, что его нет?
Спросите разработиков, как они разрабатывают. Они ж не дураки, чтобы после каждого изменения кода прокликивать все страницы. Наверняка давно уже придумали хак. Просто они не называют это “API”, поэтому не понимают, о чём вы спрашиваете.

#55

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

Вас полушать, так задача автоматизатора - без устали кодить. А на самом деле - задачи такие же, как и у ручных тестировщиков.

Не нужно путать компонентное тестирование с системным. Это с unit / integration тестами вы оперируете низкоуровневыми API. Но с чего вдруг функциональные тесты должны выглядеть точно так же? Вы что тестируете - backend или business flow приложения?

Да и что вы вкладываете в понятие “думать”? Хотите сказать, что для написания тестов не нужно думать? Еще как нужно. Но только о чем? О программировании? Вовсе нет.

Касательно развития скиллов в программировании, успешном последующем трудоустройстве и т.п. Неужели вы действительно считаете, что человек, зазубрив WebDriver API, а затем используя его в тестах, пройдет собеседование на высокую позицию? Неужели вы считете, что автоматизатор сможет выучить Java (или любой другой язык), практикуясь исключительно на написании тестов, или бултыхаясь в дебрях собственных костылей? Это просто нонсенс.

Чтобы научиться правильно думать, и тем более программировать, нужно ежедневно сидеть часами над книгами / форумами / чужим кодом и много, очень много практиковаться. Но делать это вы сможете совсем не в рабочее время, и далеко не всегда на самописных фреймворках.

А клепать PageObjects / tests конвейерами (независимо от формата) - особого ума не надо. Такой же monkey job, как с, так и без использования DSL. Так что давайте не будем рассказывать сказки о том, что предложенный вами формат поможет кому-либо постигнуть дзен программирования.

Ну так вообще-то это и является одной из основных обязанностей автоматизатора - описывать новые сценарии. Ровно как и manual QA, дизайнящий тест кейсы для ручного прогона. Только вот есть разница - будет ли человек описывать DSL на языке голого драйвера, либо при помощи хорошо продуманного абстрактного слоя.

Новый проект = как минимум 1 спринт запаса, прежде чем появится первая функциональность. При наличии опыта, данного спринта вам хватит с головой, чтобы задизайнить скелет фреймворка. Хотя, обычно люди переиспользуют старые наработки для новых проектов. Фреймворки на то и создаются. Готовые решения также никто не отменял.

Во-первых, это был не мой код. Я так не пишу и никого не побуждаю. Во-вторых, многие прекрасно знают о переносах строки: каждый вызов - новая строка. В итоге, тест выглядит практически так же, как на бумаге. В-третьих, я уже писал касательно смысловой нагрузки sendKeys. Допустим вы кому-то объясняете сценарий авторизации. Все начинается вполне безобидно, но потом из ваших уст вылетает - “а отправь-ка ключи (клавиши) со своим имейлом, а затем отправь ключи со свои паролем”. А тем временем ваш собеседник задумчиво - “хм, тебе отправить по электронке, или ‘новой почтой’ до востребования?”. Наверняка, вы совсем иначе объясняете функциональность приложения, правильно? Так чем же тесты - исключение?

Воу-воу, не торопитесь. А чем негативное тестирование принципиально отличается от позитивного в контексте уровня детализации API? Ну нужно вам ввести неверные данные, и что? Как это повлияет на степы? Вы что в первом, что во втором случае будете что-то куда-то вводить. Отличие лишь в данных (которые, к слову, должны быть отделены от бизнес логики), а также верификациях.

Надо проверить все филды на форме авторизации? Ок, создаем User entity, пишем ровно 1 тест. DataProvider'у подсовываем N записей с различными невалидными комбинациями username / password. Подсовываем DataProvider тесту - эврика! У нас ровно 1 тест, который покрывает все негативные сценарии страницы авторизации. И зачем мне вызывать низкоуровневые API тут? Чем вас loginWith(user) не устраивает? С точки зрения business flow мы делаем одни и те же операции - вводим текст в 2 филда. Какой там текст, какая у него длина и т.п. - абсолютно не важно для сценария. Важно лишь то, какое сообщение об ошибке появится (и появится ли вообще).

Классный пример, но вы сейчас уходите в крайности. Заметьте, что я не забыл упомянуть о кейсе, когда авторизацию можно вынести в прекондишен. Так что depends on…

What? :dizzy_face: Вы QA или кто? Кто, если не вы, должен знать досконально свое приложение? Как вы вообще можете дизайнить тест кейсы, если не понимаете, как работает AUT?

При правильной реализации PageObject pattern вам не нужно “думать”, на какую страницу идти, т.к. во время дизайна DSL вы возвращаете ровно те страницы, которые предполагает логика вашего приложения. Таким образом, ваши страницы и являются своеобразным навигатором по приложению. Вы чисто физически не сможете ошибиться и пойти в “неправильное” место.

Вот мы обсуждаем PageObject и DSL, но каким боком это все относится к фреймворку, объясните? Я спрашиваю потому, что ваша теория совершенно противоречит концепции фреймворков. Возьмем тот же Selenide или Serenity. Зачем среднестатистическому автоматизатору знать, какие API были использованы для реализации? Вам предоставили обертку, документацию - пользуйтесь.

Касательно WebDriver API - да, это нужно знать, если вы проектируете собственное решение. Да, это нужно знать, чтобы понимать, какие существуют возможности для взаимодействия с браузером / элементами т.п. Но вопрос же совсем не в этом. Все учебники, статьи, стримы и конференции побуждают нас к тому, чтобы мы уходили от сырых API. Даже взять в пример статью Баранцева на хабре, и его хорошие сравнения с обычными ОС драйверами. Это не то, с чем должен взаимодействовать пользователь! Для того и пишут фреймворки, чтобы обернуть низкоуровневые API, предоставив автоматизатору лишь красивую обертку. И не только ради эстетического удовольствия. Не мне вас учить об очевидных истинах избавления от дублируемости / повышению читабельности кода, переиспользуемости, инкапсуляции низкоуровневых интерфейсов и т.п. Или хотите сказать, что впервые об этом слышите? Так чем же тогда является прямое использование sendKeys в тестах - если не противоречием всем основным концепциям?

2 лайка
#56

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

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

основных обязанностей автоматизатора

Это автоматизация процессов тестирования и сценариев предоставленных мануал QA. Во всяком случае во всех местах где я работал, работаю и проходил собеседование - это так.

многие прекрасно знают о переносах строки: каждый вызов - новая строка

Как строку не переноси - это все равно ОДНА строка :slight_smile:

“а отправь-ка ключи (клавиши) со своим имейлом, а затем отправь ключи со свои паролем”. А тем временем ваш собеседник задумчиво - “хм, тебе отправить по электронке, или ‘новой почтой’ до востребования?”

Боже какая классная аналогия, првада не совсем по теме. Я в тестах никому ничего не обьясняю. Я просто пытаюсь убедиться в том что он читабелен и легок в освоении, ну и конечно выполняет свою задачу. Тест - это ТЕСТ, а не попытка обьяснить функционал. Описание теста всегда была работа для мануал QA.

невалидными комбинациями username / password.

Вы наверное не правильно поняли мой пример. Речь идет не о тестировании разных комбинацый логина/пароля. Речь идет о использовании ОДНОГО вводного поля как входящего параметра для тестирования с разными сценариями. Это не будет loginWith(), это будет typeTextToLoginField() and typeTextToPasswordField(). А потом loginWith будет использовать typeTextToLoginField and typeTextToPasswordField (исходя из Вашей логики). Так зачем мне создавать подобный мусор на странице? Чем же тут сендКейс не подходит, я не пойму. Это экшн, не не низкоуровневый АПИАЙ, это нормальный степ, который имеет право быть в тесте, а не завернут в бред типа typeTextToPasswordField(). Я не могу понять почему Вы считаете что это что то ужасное, которое нада скрыть с глаз долой. Это юзер кейс, автотест - это не обьяснение логики, это автоматические действия пользователя. Вы сильно углубились в абстракцию. Если пошагово разобрать действия пользователя, но он именно делает сендКейс, а не логинВиз. Пользователь не создает сессию драйвера, не ждет ручка выполнение запросов с бекендом, не думает о том что бы кликнуть на элемент у которого не правильное состояние. Как раз Эти все тонкости у меня завернуты в Фреймворк, что бы никто об этом не думал при написании тестов.
Если подытожить, то если какие то шаги повторяються дважды - это будет метод страницы типа loginWith, тут спора нет. Но если мне нада ОДИН раз нажать на кнопку или ввести в поле какой то текст один раз - это будет сендКейс в тесте.

Классный пример, но вы сейчас уходите в крайности. Заметьте, что я не забыл упомянуть о кейсе, когда авторизацию можно вынести в прекондишен. Так что depends on…

Это не крайности - это реалии приложений. Они становяться все сложнее и сложнее(по крайней мере у меня). И скажите мне что будет с вашими тестами, если вы вынесете это в прекондишн? Каждый тест будет логиниться и проходить по всем страницам заного, правильно? Из всего тестирвоания сколько времени будет потрачено на сами тесты, и сколько на Ваш преКондишн? Зачем это делать, обьясните? Давайте закрывать браузер еще после каждого теста, будет вообше красота. А там дальге и до перезагрузки системы не далеко :laughing:

What? :dizzy_face: Вы QA или кто? Кто, если не вы, должен знать досконально свое приложение? Как вы вообще можете дизайнить тест кейсы, если не понимаете, как работает AUT?

Воу, товарищ. Палахче! :slight_smile:
Вы наверное перепутали работу Manual QA and Automation QA (что странно). Automation QA - не дезайнят тесты, они не знают приложения досконально, потому как не проверяют его ручками каждый день. В больших компаниях, в которых я работал, ВСЕГДА есть отдельно мануальщики и автоматизаторы. Автоматизаторы - автоматизируют, а не думаю о кейсах. Не знаю как у Вас, но у меня всегда было так, и компании где я проходил собеседования используют точно такую же практику. Хотя в идеальном мире было бы круто что бы автоматизаторы делали все! Но такой мир еще не настал :slight_smile:

При правильной реализации PageObject pattern вам не нужно “думать”, на какую страницу идти, т.к. во время дизайна DSL вы возвращаете ровно те страницы, которые предполагает логика вашего приложения. Таким образом, ваши страницы и являются своеобразным навигатором по приложению. Вы чисто физически не сможете ошибиться и пойти в “неправильное” место.

Да, но Вам нада знать куда и за чем идти. Зачем это нужно? Вызвал invoke(), и пусть оно само найдет где сейчас приложение, и куда ему нада дошагать. Ведь в конце концов Вам нада работать со страницой, правильно?

ваша теория совершенно противоречит концепции фреймворков.

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

Этот спор может длиться вечно, и думаю без бутылки его продолжать безсмысленно (так говорил мне мой бывший работодатель :)).
Напишите лучше какова ваша структура проэкта автотестов :slight_smile:

1 лайк
#57

Дальше можно не продолжать. Расходимся.

2 лайка
#58

Даже и не знаю. Ну у меня действительно такая практика была весь мой автоматизаторский опыт, и в Украине и в Канаде. Да конечно какие то перфоманс и лоад тестирование мы придумывали и делали, но остальное было именно так как я написал, через Манул КЬЮА тим. В Nuance, Intell, Ericsson, Worldpay компаниях так процес построен.
Может они и я делаем все не так? Вы обьясните, а то я чувствую что Вы так разочарованы моим суждение что не видите смысла дальше мне что то обьяснять, потому как я не понимаю каких то очень примитивных вещей. :frowning:

1 лайк
#59

Я сейчас работаю на одну компанию. Сценарии (то бишь, тест-кейсы, причем сразу в Gherkin) мне предоставляют мануальщики. Мое дело - все перевести в код.

2 лайка
#60

Еще один взгляд на “идеальную структуру”, если кто не видел еще:
Frameworks-shrameworks or how to ruin your test automation (Mikalai Alimenkou, Ukraine)

3 лайка