Перед людьми, которые начинают писать тесты на Java, стоит вполне конкретный выбор: писать на чистом Selenium или Selenide? Вот статья и помогает принять решение.
Да, формально Selenium не инструмент для тестирования, но очень многие его именно так и используют. Фактически дописывая недостающий функционал каждый раз заново.
А, ну так вы говорите про юнит-тесты, видимо. Такие инструменты, как PhpUnit, Jest, JUnit, TestNG позволяют писать и запускать тесты, но сами по себе не дают доступа к браузер.
Для полноценных End-to-End тестов нужен ещё инструмент для оперирования браузером типа Selenium/Selenide.
имеет ли смысл осваивать такие штуки, есть на основных своих языках уже юзаешь специализированные тестовые фреймворки?
Вопрос не понял, но ответ зависит от ваших потребностей. Кому-то имеет, кому-то не имеет. И кстати, что такое "специализированные тестовые фреймворки"?
Нет, это решение точно не для того, чтобы не писать код. Это решения как раз для того, чтобы писать код.
Да, в селениде есть плюшки. Да, в селениде меньше кода. Да, это реальный код на Java. Да, он похож на jquery.
Юмор в том, что как раз с чистым вебдрайвером Stale Element Reference намного чаще возникает. А с Селенидом (почти) никогда. Кроме итерирования коллекции, но это само по себе плохая идея.
Разница в том, что в парном программировании оба вовлечены в процесс, причём в одно и то же время.
А в паре «разработчик-тестеровщик» задача постоянно перелетает от одного к другому, и каждый должен постоянно переключаться между этой и другими задачами. Это и утомляет, и занимает время и т.д.
Дело в том, что тестов обычно больше, чем кода. По крайней мере для некоторых участков кода. Иную строчку покрывает N тестов. Поэтому держать тесты прямо в коде просто не получится.
Ошибка.
Именно так и происходит: когда разработчик начинает писать тест, его мозг переключается из "созидательного" в "критический" режим, и он начинает придумывать разные ситуации, в которых его код может сломаться. Это помогает не только тесты написать, но и тут же улучшить код, не дожидаясь всего этого долгого процесса релиза/установки/тестирования/багфикса.
1. Так JQuery тут не при чём. Вещи типа `#id` и `.class` — это обычные CSS селекторы. Они были до JQuery и будут после JQuery. Миллионы людей используют их в Chrome developer tools при разработке и отладке без всяких JQuery.
3. Список элементов по селектору можно получить вот так: `$$(".class")`. Скорость этой операции никак не зависит от таймаутов. Она зависит только от количества элементов (ну и тормознутости браузера).
И да, таймаут легко задать свой: `Configuration.timeout = 8000`
4. Для JUnit5 тоже есть поддержка: selenide.org/javadoc/current/com/codeborne/selenide/junit5/package-summary.html
Тут есть разные мнения, но точно скажу, что JUnit как минимум не хуже, чем TestNG, умеет запускать тесты параллельно. Время запуска тестов гораздо больше зависит от самих тестов и AUT, чем от тестового фреймворка.
Думаю, имелось в виду, что зло не фича тогглы, а процесс, когда все подряд коммитят в мастер. А вот когда все коммитят в разные ветки, то они ломают только свои ветки. А в мастер мержат только зелёные ветки, поэтому мастер, как правило, зелёный.
Selenide тоже поддерживает аннотации @FindBy, если что.
(хоть они там не особо-то нужны)
Если что, в селениде все эти вещи тоже можно легко делать.
А, ну это да, сама по себе статья отвратительная. Мне казалось, это и так очевидно. :)
А какого именно "контроля над браузером" не хватило?
Сравнение как раз вполне логичное.
Перед людьми, которые начинают писать тесты на Java, стоит вполне конкретный выбор: писать на чистом Selenium или Selenide? Вот статья и помогает принять решение.
Да, формально Selenium не инструмент для тестирования, но очень многие его именно так и используют. Фактически дописывая недостающий функционал каждый раз заново.
А, ну так вы говорите про юнит-тесты, видимо. Такие инструменты, как PhpUnit, Jest, JUnit, TestNG позволяют писать и запускать тесты, но сами по себе не дают доступа к браузер.
Для полноценных End-to-End тестов нужен ещё инструмент для оперирования браузером типа Selenium/Selenide.
Похоже на то. :)
Да вообще это был ужасный текст в оригинале, в нём полно подобных ошибок. Зачем его взялись переводить?..
Вопрос не понял, но ответ зависит от ваших потребностей. Кому-то имеет, кому-то не имеет. И кстати, что такое "специализированные тестовые фреймворки"?
Нет, это решение точно не для того, чтобы не писать код. Это решения как раз для того, чтобы писать код.
Да, в селениде есть плюшки. Да, в селениде меньше кода. Да, это реальный код на Java. Да, он похож на jquery.
А с картинкой-то что не так?
Юмор в том, что как раз с чистым вебдрайвером Stale Element Reference намного чаще возникает. А с Селенидом (почти) никогда. Кроме итерирования коллекции, но это само по себе плохая идея.
Начнёте писать тесты — и качество кода повысится.
А в паре «разработчик-тестеровщик» задача постоянно перелетает от одного к другому, и каждый должен постоянно переключаться между этой и другими задачами. Это и утомляет, и занимает время и т.д.
Ошибка.
Именно так и происходит: когда разработчик начинает писать тест, его мозг переключается из "созидательного" в "критический" режим, и он начинает придумывать разные ситуации, в которых его код может сломаться. Это помогает не только тесты написать, но и тут же улучшить код, не дожидаясь всего этого долгого процесса релиза/установки/тестирования/багфикса.
См. https://www.youtube.com/watch?v=8u6_hctdhqI&feature=youtu.be&a
Знаю точно, что в Эстонию можно. :)
P.S. Ну и вообще-то проблемы с самооценкой есть абсолютно у всех на свете. Больше или меньше, заметно или незаметно — но есть.
3. Список элементов по селектору можно получить вот так: `$$(".class")`. Скорость этой операции никак не зависит от таймаутов. Она зависит только от количества элементов (ну и тормознутости браузера).
И да, таймаут легко задать свой: `Configuration.timeout = 8000`
4. Для JUnit5 тоже есть поддержка: selenide.org/javadoc/current/com/codeborne/selenide/junit5/package-summary.html
Тут есть разные мнения, но точно скажу, что JUnit как минимум не хуже, чем TestNG, умеет запускать тесты параллельно. Время запуска тестов гораздо больше зависит от самих тестов и AUT, чем от тестового фреймворка.
Не совсем так. В одном тесте нельзя делать несколько "act" (из парадигмы arrange-act-assert). А вот "arrange" и "assert" вполне может быть несколько.
Отключить эти ворнинги, как минимум в тестах.