1. Костыли это не разрастание количества сценариев, с этим то как раз все ок. Проблемы будут, когда ваш фреймворк не будет справляться с очередным сценарием. Представьте, что у вас количество типов ивентов дойдет до 100. У вас в коде будет 100 «ифов»?) Не хотел бы я дебажить такой код. Но, повторюсь, не факт, что у вас будут такие проблемы, просто для примера, почему бы и не стал использовать такой подход.
2. Дело вкуса значит, спорить не буду
3. Есть yaml схемы, можно также использовать и json схемы. Но опять же дело вкуса. Мне вообще не нравится как xml выглядит, не отношу его к разряду удобных для чтения человеком.
P.S. кстати, у вас уже есть костыль в вашем решении — теги
Спасибо за статью, но так и не понял зачем было делать такое? :)
1. ИМХО, все попытки сделать универсальный конвертер из одного в другое (в вашем случае это конвертация xml в команды вебдрайвера) — тупиковая ветка. Вы сами загоняете себя в рамки, обходить которые со временем можно будет только с помощью костылей. Хотя, если ваше приложение особо развиваться не будет, и вам удалось уже на старте предусмотреть все нюансы, то, возможно, решение будет жить долго.
2. Утверждение, что тесты писать быстрее, если они не записаны кодом — сомнительно. Чем оно подкреплено? В коде букв будет меньше, очевидно:
Тест на java
@Test(dataProvider = "searchKey")
public void searchTest(String searchKey) {
List<GoogleResult> results = googleApp.searchFor(searchKey);
results.forEach(r -> soft.assertThat(r)
.as("Search result is not relevant")
.contains(searchKey)
);
soft.assertAll();
}
Примерно в 4 раза меньше символов, чем у вас в xml, так еще и проверка есть.
3. Еще минус xml в том, что его трудно читать. YAML получше будет.
4. Ну и CI и Selenium Server нужно на старте закладывать, чтобы потом не было непредвиденных проблем в архитектуре фреймворка.
И все же, вторая мысль — возвращаемое значение метода Until не используется в большинстве случаев.
Так и не понял откуда такой вывод. Если возвращает bool значение, то не нужно — тут ок. Если элемент, то нужно, чтобы еще раз не опрашивать драйвер. По этой логике в большинстве случаев мы хотим получать bool, но это же не так. Для поиска каждого элемента нужно ожидание. И в большинстве случаев мы все же будем использовать возвращаемое значение. Или я что-то не уловил?
Автор, вы не уловили суть библиотеки Rest-Assured. Посмотрели бы примеры использования для начала. У вас она просто в качестве http-клиента, но это как из пушки по воробьям. Примерно вот так можно переписать ваш первый пример:
import org.hamcrest.Matchers;
import org.testng.annotations.Test;
import static io.restassured.RestAssured.*;
public class TestTest {
@Test
public void test() {
given()
.get("http://restcountries.eu/rest/v1/name/russia")
.then()
.body("[0].capital", Matchers.equalTo("Moscow"));
}
}
Не хватило новизны, нестандартности, интересных решений — всего того, что хочется почерпнуть на Хабре. Ваша статья больше похожа просто на пиар Автотеки — мы есть, мы тестируем.
На вкус и цвет, как говорится. Некоторым нравится использовать «знания об огромном джава мире» в тестах. К тому же, часто стек автоматизации подбирают под стэк разработки. Чтобы плотнее могли взаимодействовать девелоперы и тестеры.
Как минимум половина таких многочленов (любой длины) оканчивается на 0 и поэтому раскладывается (с ожидаемым корнем x=2)
У всех чисел, полученных перемножением двух больших простых чисел, не будет множителя 2. Значит все многочлены, полученные из ключей RSA будут оканчиваться на 1.
Неплохо, но все равно выглядит как-то костыльнно :)
Я про логику динамического формирования заглушки: метод `setscenario` записывает переменные, а остальные их считывают. А можно в скрипте SoapUi создавать новую заглушку (заглушка создает заглушку, хехе)? Так было бы более канонично, плюс убивать ее сразу после теста.
Ну и параллелить точно уже не получится при таком подходе (ну либо очень осторожно).
А почему не рассматриваете развитие в сторону какого-нибудь мок-сервера (тот же WireMock)? SoapUi все-таки больше инструмент для ручных тестов, в нем нет той гибкости, какую нам могут предложить различные специализированные библиотеки.
Если честно, это дичь какая-то)
Во-первых, по оформлению — код скринами, нет примеров самих тестов.
Во-вторых, почему бы не сделать нормальные модели данных, а не эти ужасные классы BasePojo? Json файл можно очень быстро перегнать в класс Java с помощью плагина для IDE, и потом сделать нужные конструкторы или билдеры для формирования тестовых данных.
В-третьих, вы Rest-Assured используете только для отправки запроса и десериализации? Это как их пушки по воробьям, имхо. Проще взять http-клиент и тот же Jackson, а не тащить «толстый» Rest-Assured, как правильно заметили в предыдущем комменте.
В любом случае, опыт, конечно интересный. Но мне кажется, что выводы у вас неверные по результатам эксперимента.
Мы не хотим больше Selenium — давайте нам Puppeteer!
Вот сделали бы сравнение — чем Puppeteer, по-вашему, лучше.
Хотя, какие бы плюсы не нашлись, они вряд-ли перекроют эти два от Selenium: поддержка более одного браузера и громадное количество оберток для всех популярных ЯП.
Вы согласовываете общие высокоуровневые KPI и начинаете проект
А можно пример? Нельзя же прийти к спонсору и сказать «Ну вы дайте денег, мы начнем, а там посмотрим». Они же хотят посчитать ROI, а без оценки денег и времени этого нельзя сделать.
Статья хоть и неплохая, но тоже очень поверхностная. Я бы не рекомендовал ее как руководство к действию для неопытного скрам-мастера. Если хотите научиться проводить классные ретро, то нужно прочитать больше материала. Ну и, конечно, после каждой практики проводить для себя ретроспективу по проведенной ретроспективе.
По канонам срама команда должна быть кросс-функциональной — т.е. иметь все компетенции, которые нужны. Можно самим научиться поднимать тестовые окружения или забрать одного «девопса» себе в команду
Ну так генерация тестовых данных, это же не тест. Тест говорит — мне нужна фирма в таком-то городе, с таким-то параметром — и ему ее предоставляют. В тесте нет никакого рандома. Единственный минус такого подхода, что долго получать данные из базы и есть небольшой риск, что данных вообще может не оказаться.
Я не защищаю такой подход, но он вполне может существовать на временной основе, пока не сделают генерилку данных. В нем нет каких-то фундаментально-неверных подходов.
Тут рандом не в тестах, а в подборе тестовых данных. Например, есть кейс: проверить адреса офисов, которые возвращает API по фирме. По какой фирме делать запрос? Можно по одной и той же каждый раз, а можно выбирать каждый раз рандомную фирму. Разумеется, тест с рандомной фирмой можно повторить, так как мы пишем лог теста.
Второй вариант получше, все же будет.
На у совсем хороший подход — самим генерить фирму с нужными параметрами, используя классы эквивалентности. Но это может оказаться весьма трудоемко.
2. Дело вкуса значит, спорить не буду
3. Есть yaml схемы, можно также использовать и json схемы. Но опять же дело вкуса. Мне вообще не нравится как xml выглядит, не отношу его к разряду удобных для чтения человеком.
P.S. кстати, у вас уже есть костыль в вашем решении — теги
1. ИМХО, все попытки сделать универсальный конвертер из одного в другое (в вашем случае это конвертация xml в команды вебдрайвера) — тупиковая ветка. Вы сами загоняете себя в рамки, обходить которые со временем можно будет только с помощью костылей. Хотя, если ваше приложение особо развиваться не будет, и вам удалось уже на старте предусмотреть все нюансы, то, возможно, решение будет жить долго.
2. Утверждение, что тесты писать быстрее, если они не записаны кодом — сомнительно. Чем оно подкреплено? В коде букв будет меньше, очевидно:
Примерно в 4 раза меньше символов, чем у вас в xml, так еще и проверка есть.
3. Еще минус xml в том, что его трудно читать. YAML получше будет.
4. Ну и CI и Selenium Server нужно на старте закладывать, чтобы потом не было непредвиденных проблем в архитектуре фреймворка.
Так и не понял откуда такой вывод. Если возвращает bool значение, то не нужно — тут ок. Если элемент, то нужно, чтобы еще раз не опрашивать драйвер. По этой логике в большинстве случаев мы хотим получать bool, но это же не так. Для поиска каждого элемента нужно ожидание. И в большинстве случаев мы все же будем использовать возвращаемое значение. Или я что-то не уловил?
У всех чисел, полученных перемножением двух больших простых чисел, не будет множителя 2. Значит все многочлены, полученные из ключей RSA будут оканчиваться на 1.
Я про логику динамического формирования заглушки: метод `setscenario` записывает переменные, а остальные их считывают. А можно в скрипте SoapUi создавать новую заглушку (заглушка создает заглушку, хехе)? Так было бы более канонично, плюс убивать ее сразу после теста.
Ну и параллелить точно уже не получится при таком подходе (ну либо очень осторожно).
А почему не рассматриваете развитие в сторону какого-нибудь мок-сервера (тот же WireMock)? SoapUi все-таки больше инструмент для ручных тестов, в нем нет той гибкости, какую нам могут предложить различные специализированные библиотеки.
И добавить конструкторы или билдеры, для «генерировать все на лету». Это было бы удобнее читать и править при необходимости.
про это бы написали. Какие еще рассматривали инструменты (кроме, разумеется, RF), почему не подошли.
Во-первых, по оформлению — код скринами, нет примеров самих тестов.
Во-вторых, почему бы не сделать нормальные модели данных, а не эти ужасные классы BasePojo? Json файл можно очень быстро перегнать в класс Java с помощью плагина для IDE, и потом сделать нужные конструкторы или билдеры для формирования тестовых данных.
В-третьих, вы Rest-Assured используете только для отправки запроса и десериализации? Это как их пушки по воробьям, имхо. Проще взять http-клиент и тот же Jackson, а не тащить «толстый» Rest-Assured, как правильно заметили в предыдущем комменте.
В любом случае, опыт, конечно интересный. Но мне кажется, что выводы у вас неверные по результатам эксперимента.
Вот сделали бы сравнение — чем Puppeteer, по-вашему, лучше.
Хотя, какие бы плюсы не нашлись, они вряд-ли перекроют эти два от Selenium: поддержка более одного браузера и громадное количество оберток для всех популярных ЯП.
А можно пример? Нельзя же прийти к спонсору и сказать «Ну вы дайте денег, мы начнем, а там посмотрим». Они же хотят посчитать ROI, а без оценки денег и времени этого нельзя сделать.
Я не защищаю такой подход, но он вполне может существовать на временной основе, пока не сделают генерилку данных. В нем нет каких-то фундаментально-неверных подходов.
Второй вариант получше, все же будет.
На у совсем хороший подход — самим генерить фирму с нужными параметрами, используя классы эквивалентности. Но это может оказаться весьма трудоемко.