Pull to refresh

Comments 17

Вопрос: имеет ли смысл осваивать такие штуки, есть на основных своих языках уже юзаешь специализированные тестовые фреймворки?

То есть, это решения для того, чтобы код не писать (писать псевдокод, писать его как можно меньше), или тут есть ещё много плюшек, добавочно?

И кстати да, а верное ли впечатление, что тут кода меньше? И что это не вполне код? Чисто внешне подозрительно похоже на jquery.

ЗЫ ни разу не юзала ни селениум, ни селенид,
недавно только наткнулась тут на комментарий чей-то, мол "было у них в вакансии про селениум, я сказал - юзаю селенид, и меня не взяли, поскольку эйчар не знал, что они в целом родственные". И тут статья с такими же терминами в названии - невозможно было пройти мимо.

имеет ли смысл осваивать такие штуки, есть на основных своих языках уже юзаешь специализированные тестовые фреймворки?

Вопрос не понял, но ответ зависит от ваших потребностей. Кому-то имеет, кому-то не имеет. И кстати, что такое "специализированные тестовые фреймворки"?

Нет, это решение точно не для того, чтобы не писать код. Это решения как раз для того, чтобы писать код.

Да, в селениде есть плюшки. Да, в селениде меньше кода. Да, это реальный код на Java. Да, он похож на jquery.

"Специализированные тестовые" в моём случае PhpUnit для PHP и Jest для Vue.js.

Грубо говоря, вопрос, даёт ли Селенид добавочные возможности, если вы изначально пишете по TDD, уже на входе используя вот такое вот всё.

А, ну так вы говорите про юнит-тесты, видимо. Такие инструменты, как PhpUnit, Jest, JUnit, TestNG позволяют писать и запускать тесты, но сами по себе не дают доступа к браузер.

Для полноценных End-to-End тестов нужен ещё инструмент для оперирования браузером типа Selenium/Selenide.

С трудом могу представить более сложное описание и сравнение этих инструментов, ну и явно бросающиеся в глаза противоречия - то Селениум нельзя для тестов, то замечательный, специально написанный для тестирования веб приложений инструмент. Но для маркетинга наверное важно показать, как все сложно и запутанно.

А можно тогда я вас тоже спрошу (если в статье только маркетинг): стоит ли программисту, уже использующему специализированные языковые тестовые фреймворки вот эти вот два инструмента осваивать? Какие-то плюшки будут от этого, программисту?
(из статьи реально не поняла)

по всем признакам это перевод с английского

Поэтому на основе Selenium было создано несколько инструментов, таких как FluentLenium, Fluent-selenium, HTMLElements, Thucydides, Yandex, Watir-webdriver. 

Наверное имелось в виду, что Html Elements от компании Yandex ?

Похоже на то. :)

Да вообще это был ужасный текст в оригинале, в нём полно подобных ошибок. Зачем его взялись переводить?..

К сожалению по части тестирования у них очень сомнительная экспертиза - большинство статей на хабре кричит об этом.

там у них уже вместо HtmlElements — Atlas — штука интересная, но к сожалению — прекратившая развитие.
Selenide — это враппер вокруг Selenium. Каким фигом их сравнивают — непонятно. Это примерно как «JavaScript или React.js — что из этого лучше?»

Сравнение как раз вполне логичное.

Перед людьми, которые начинают писать тесты на Java, стоит вполне конкретный выбор: писать на чистом Selenium или Selenide? Вот статья и помогает принять решение.

Да, формально Selenium не инструмент для тестирования, но очень многие его именно так и используют. Фактически дописывая недостающий функционал каждый раз заново.

Нет, я немного не про это.

Согласен, Selenium используется для управления браузером, но Selenide просто добавляет собственные удобные (иногда IMHO спорно) вещи.

Я про то, что в статье сравнивают как бы противопоставляя Selenide Selenium'у («Selenide vs Selenium»), там говорится следующее: «Selenium, так же как и Selenide, являются фреймворками автоматизации тестирования, и вы можете обнаружить некоторые сходства в их работе». Selenide — это производный от Selenium продукт (как его автор вы это знаете, я просто для связанности это пишу, чтобы более точно выразиться), который его использует внутри себя, попутно пытаясь решать какие-то сопутствующие проблемы чистого Selenium (в некоторых случаях не решает, к сожалению), построен на его базе и, собственно, дает к нему доступ через getWebDriver(). Было бы удивительно, если бы там не было сходств.

С сопоставлением того, как какие-то вещи можно делать и там, и там, я согласен, не согласен с противопоставлением одного другому, как если бы JavaScript противопоставляли React.

Сам пробовал и то, и то, в итоге отказался от Selenide в пользу чистого Selenium, потому что оказалось, что в моем случае с ним получается более полный контроль над работой браузера.

Я не против Selenide, я против написания таких статей. Не могу согласиться, что такая статья, на мой вкус достаточно поверхностная, помогает принять решение использовать Selenide или Selenium, максимум решение захотеть попробовать, как работает Selenide, слишком мало практических примеров.

Статья называется «подробное сравнение», я там насчитал аж 9 строчек кода. Черновик W3C на WebDriver содержит список действий по сути, которые могут быть выполнены при помощи WebDriver. Было бы отлично, если бы что-то из этих действий было отображено в статье, и потом показано, в чем может быть проблема, и как она решается в Selenide, или пример, в чем он лучше. Это не настолько маленький проект, чтобы подробное сравнение включало всего 9 строчек кода, 4 из которых это пример как что-то кликнуть. А где остальное-то?

А, ну это да, сама по себе статья отвратительная. Мне казалось, это и так очевидно. :)

А какого именно "контроля над браузером" не хватило?

Это было около 3.5 лет назад, насколько я помню, в силу специфичности структуры приложения нужно было контролировать тайминги более детально, с точки зрения кода оказалось проще взять голый Selenium и написать части для «окончательных» WebElement'ов, которые были найдены, но между нахождением элемента и кликом по нему он ререндерится и получает новый идентификатор много раз подряд, потому что дочерние элементы изменились.

Плюс надо было оптимизировать по скорости, чтобы больше тестов проходило за то же время без потери стабильности и роста false negative. Когда много жонглируешь implicitlyWait вручную, несколько теряется смысл использовать Selenide, потому что с ним придется делать то же, что и с голым Selenium. А потом «всё заверте», и в итоге написана и часть для скриншотов через JUnit5 при падении тестов, и всё остальное.

Если что, в селениде все эти вещи тоже можно легко делать.

Sign up to leave a comment.