JavaScript
Node.JS
Angular
Web services testing
TypeScript
Comments 17
+6

В который раз пишу — ну не ставьте вы tsc глобально, забудьте как страшный сон. TSC это то, от чего зависит ваш проект. Он должен стоять локально. Это даст вам возможность:


  • Иметь разные тайпскрипты для разных версий одновременно
  • Не бояться апдейтить tsc для одного или нескольких проектов

Если все таки надо что-то глобальное (например angular/cli или create-react-app) лучше воспользоваться npx — подробнее тут.

+1

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

0
Спасибо за упоминание
"...WebDriver, умеет работать только с конечным набором локаторов. Этот список можно посмотреть на сайте w3.org...."
, а то давно пользуюсь но никогда не доходили руки посмотреть именно спецификации.
Но в связи с вышеописанным возник вопрос — так кто кому следует, собственно?
Ибо по ссылке можно прочитать
«This specification is derived from the popular Selenium WebDriver browser automation framework.»
— тоесть этот стандарт написан по мотивам селениума. Но и стандарт, и селениум — они как-бы не статичны, да и конторы их пилят немного разные…
+2

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

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

Расскажите пожалуйста чуть подробнее — в каких случая необходимо запускать и гасить selenium-сервер между запусками тестов?
0
Привет. Имелось в виду между запусками не в рамках одного набора, а между глобальными запусками.
Например, если вы запускаете пачку тестов два раза в день, между этими событиями нет смысла держать selenium-сервер запущенным.
0
Аа понял, спасибо! А у вас случайно нет линки на проект с хорошим примером где такое используется или статью?
+1
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()));
+1
Привет.

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

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

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

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

Во всем остальном — шикарные дополнения, спасибо Вам!
+1
Пытался все делать по инструкции, но застрял в этом месте
«Для запуска нашего теста сначала надо превратить TS-код в JS-код, а затем запустить его:
$  tsc
$  protractor output_js/config.js

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


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

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

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

то попробуйте команду
npx protractor output_js/config.js

npx поищет протрактор в папке node_modules внутри вашего проекта, ибо по дефолту всё ищется в глобальной директории.
0
В инструкции я только вижу, что protractor указан в зависимостях.
Также там указано, как глобально ставить TS, а о Protractor ни слова.
Я просто в js/ts/node новичок, поэтому еще не очень понимаю, что здесь происходит, пытаюсь все делать пошагово.
+1
TS, protractor и все остальные зависимости должны быть в package.json. Тогда после инстала можно будет запустить протрактор через npx, как я писал выше. А то, что что-то не работает — это хорошо ) Так мы учимся. Это к автору статьи. Что-то он не точно описал.
В статье typescript он поставил и локально и глобально. Поэтому tsc у вас должен работать. А вот протрактор в статье только локально. А на машине у него, видать, ещё и глобально стоит. Поэтому команда протрактора без npx у него работает, а у вас нет.
Only those users with full accounts are able to leave comments., please.