Разворачиваем автоматизацию за пару часов: TypeScript, Protractor, Jasmine

[@nizkopal]

Да, это разумно, спасибо за замечание и ссылку.

[@L2jLiga]

В protactor ^5 под капотом используются Jasmine 2.x и jasminewd2(адаптер jasmine 2 -> webdriver) и правильно было бы в зависимостях использовать тайпинги для второго Jasmine и тайпинги для адаптера. Так что я бы поставил бы @types/jasmine@^2 и @types/jasminewd2.
А вот в Protractor 6 уже используется третий Jasmine без всяких "сторонних" адаптеров.

[@nizkopal]

Спасибо, не знал этого. Поправлю!

[@mkovalevskyi]

Спасибо за упоминание

"...WebDriver, умеет работать только с конечным набором локаторов. Этот список можно посмотреть на сайте w3.org...."

, а то давно пользуюсь но никогда не доходили руки посмотреть именно спецификации.
Но в связи с вышеописанным возник вопрос — так кто кому следует, собственно?
Ибо по ссылке можно прочитать

«This specification is derived from the popular Selenium WebDriver browser automation framework.»

— тоесть этот стандарт написан по мотивам селениума. Но и стандарт, и селениум — они как-бы не статичны, да и конторы их пилят немного разные…

[@Cerberuser]

По формулировке похоже, что Selenium сгенерировал начальный вариант, а W3C его с некоторыми модификациями принял как стандарт, которому теперь следует в том числе и сам Selenium.

[@pettit3301]

nizkopal

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

Расскажите пожалуйста чуть подробнее — в каких случая необходимо запускать и гасить selenium-сервер между запусками тестов?

[@nizkopal]

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

[@pettit3301]

Аа понял, спасибо! А у вас случайно нет линки на проект с хорошим примером где такое используется или статью?

[@Gennadii_M]

TypeScript отличается от JavaScript поддержкой использования полноценных классов

Это есть и в JS начиная с ES2015 (ES6).

и возможностью подключения модулей

А как же JS без этого живёт ) Разница в синтаксисе. TS — import, js стремится к тем же импортам, но изначально юзается require.

не “скомпилируется”, если вместо int в функцию где-то явно передается string

В JS нет типа данных int. Вместо него — number.

У меня уже были установлены NodeJS (v11.6.0)

Не то, чтобы это было критично, но не рекомендуется использовать версии ноды с нечётной мажорной версией, ибо это бета версия для будущей LTS. Обычно нода предлагается в 2-ух версиях — LTS и Current. Последняя содержит новые фичи, но ещё не является окончательной. Но обе они имеют чётную мажорную версию. Например сейчас — 10.15.3 LTS и 12.3.0 Current.

npm install -g typescript

Лучше ставить локально. На другйо машине версия может отличаться и всё пойдёт крахом )

SELENIUM_PROMISE_MANAGER: false

я уже давненько не юзал протрактор, но по идее эта строчка уже лишняя. Почти год назад как контрол флоу должны были полностью убрать: https://github.com/SeleniumHQ/selenium/issues/2969

Tests/*Test.js

Обычно принято заканчивать имя теста на *spec.js, но то не принципиально.

Особой разницы нет, просто мне привычнее работать с jar-файлом

Я бы не сказал, что особой разницы нет, т.к. webdriver-manager сам хендлит за вас работу с драйверами. Нет нужды искать какая версия драйвера соответствует новой версии браузера. Вебдрайвер-менеджер делает это за вас, посему является более предпочитетльным.
Если на проекте скучно, то можно, конечно, и руками )

await browser.wait(EC.presenceOf(input_button), 5000);

Как для примера пойдёт, но explicit wait здесь лишний во всём тесте. Там и так всё достаточно быстро работает +, если я не ошибайюсь, то дефолтный implicit wait — пол секнды — подстрахует )

Это означает, что код не всегда выполняется в том порядке, в котором он написан.

Вот тут путаете ) Код всегда выполняется именно в том порядке, в котором он написан. Там ничего случайного нет. Разница в том когда вы получите результат асинхронного кода.

const myObj = {myVar: null};
function asyncChanger(obj, prop, value) {
  setTimeout(() => obj[prop] = value, 1000);
}
asyncChanger(myObj, 'myVar', 42);

Здесь функция asyncChanger будет вызвана именно там, где она написана, но переменная изменится через секунду. Если инетерсно — могу дать пару ссылок с подробным разбором асинхронности в JS.

нам пригодится функция then()

Выше ж был код на async/await, а теперь обратно к промисам вернулись ) Можете запутать неопытного читателя. Промисы — это был прорыв в организации асинхронного кода, но async/await — следующий и более удобный шаг.

Он позволяет избегать promise hell, который раньше образовывался в коде из-за большого количества вложенностей

Тут не совсем точно. Промисы как раз позволили избавиться от callback hell. Но строить вложенности можно и на промисах. Таким страдают неопытные разработчики, особенно, которые долго сидели на колбеках.
Good:

getText()
  .then(text => someInputField.sendKeys(text))
  .then(() => someFinalization());

Bad:

getText()
  .then(text => someInputField.sendKeys(text)
    .then(() => someFinalization()));

[@nizkopal]

Привет.

Вот тут путаете ) Код всегда выполняется именно в том порядке, в котором он написан. Там ничего случайного нет. Разница в том когда вы получите результат асинхронного кода.
<...>
Здесь функция asyncChanger будет вызвана именно там, где она написана, но переменная изменится через секунду. Если инетерсно — могу дать пару ссылок с подробным разбором асинхронности в JS.

Я, само собой, это и имел в виду. :)
Но уточнение стоящее.

Если инетерсно — могу дать пару ссылок с подробным разбором асинхронности в JS.

Кидайте, конечно. Всем пригодится, кто сюда заглянет.

Во всем остальном — шикарные дополнения, спасибо Вам!

[@Gennadii_M]

Про асинхронность — www.youtube.com/watch?v=HB9YjdQYkQY
Больше про применение и подводные камни в автоматизации — www.youtube.com/watch?v=aY3KTwDp2zU

Если что — всегда рад помочь )

[@algot]

Пытался все делать по инструкции, но застрял в этом месте

«Для запуска нашего теста сначала надо превратить TS-код в JS-код, а затем запустить его:

$  tsc
$  protractor output_js/config.js

Наш тест запустился — мы молодцы. :)»

Почему мы в консоли должны писать «protractor»? Консоль не знает такой команды.
Пробовал писать

node .\output_js\config.js

но тогда ничего не происходит.

Подскажите, как правильно.

[@Gennadii_M]

Протрактор — фреймворк, который запускает и ранит тесты. В конфиге для ноды мало что интересного есть )
Для дебага мало инфы, но есть подозрение, что у автора протрактор стоит глобально и тогда его команда работает. А у вас нет. Если вы делали в проекте

npm install protractor

то попробуйте команду

npx protractor output_js/config.js

npx поищет протрактор в папке node_modules внутри вашего проекта, ибо по дефолту всё ищется в глобальной директории.

[@algot]

В инструкции я только вижу, что protractor указан в зависимостях.
Также там указано, как глобально ставить TS, а о Protractor ни слова.
Я просто в js/ts/node новичок, поэтому еще не очень понимаю, что здесь происходит, пытаюсь все делать пошагово.

[@Gennadii_M]

TS, protractor и все остальные зависимости должны быть в package.json. Тогда после инстала можно будет запустить протрактор через npx, как я писал выше. А то, что что-то не работает — это хорошо ) Так мы учимся. Это к автору статьи. Что-то он не точно описал.
В статье typescript он поставил и локально и глобально. Поэтому tsc у вас должен работать. А вот протрактор в статье только локально. А на машине у него, видать, ещё и глобально стоит. Поэтому команда протрактора без npx у него работает, а у вас нет.

[@algot]

Спасибо, npx помог