Лайхак — это что-то необычное. Нестандартное применение стандартным вещам. Например, сделать начадку-вентилятор на дрель и раздувать этим делом угли или прокчировать пейджи с элементами, чтобы получить автоматическое логгирование. И, видя заголовок про лайфхаки, я ожидал увидеть именно это, а не «дуйте на угли, чтобы их раздуть» или «используйте typescript, бо у него автокомплит есть».
Я не говорю, что статья не имеет права на жизнь, но контент не соответствует названию (имхо, конечно же).
Мне одному кажется, что это не совсем лайфхаки, а скорее подходы и практики? При чём многие из них достаточно очевидны. Например «фиксируйте баги» — а как иначе то? Шаблонным строкам уже 5-ый год от роду и это довно считается best practice, но никак не лайфхаком. Стрелочные функции туда же. Только я бы добавил, что не всегда нужно «избегать проблем с указателем this из JavaScript». Сделайте так с итом в моке и поменяте this.retries(2).
Задача ставилась, но решение с кукумбером было на столько сложным к написанию, что задачи писать тесты не автоматизаторам не было. Написано было на английском не как код, да, но писать самому аналитику — вообще никак )
Вы знаете аналитика без знаний программирования, который может сам писать тесты на кукумбере? А моём опыте это было чрезмерно сложно, как в написании, так и в поддержке.
Я пишу на тайпскрипте, тест раннер — jasmine. Мануальщики код тестов читают без проблем. Заказчик не читает тесты вообще. Ни в коде и в tms.
Единая точка входа — это, конечно хорошо, но только тогда когда тест кейсы написанные мануальщиком автоматически становятся авто тестами. Если их всё равно надо переписывать в авто тесты, то смысл пропадает. А именно так и происходит в 100% случаев, про которые я слышал и видел сам.
А сам кукмбер — это лишний слой абстракции, который накладывает значительные ограничания на архитектуру, которые надо как-то извращённо-костыльно решать.
Не каждый бизнес аналитик пишет тесты ) Это раз, два — у меня был проект на кукумбере. Я туда пришёл на синьёрную позицию и первые 3 месяца не мог самостоятельно писать тесты как раз из-за кукумбера (конечно, там было не самое лучшее решение и можно сделать лучше, но проблемы всё равно есть в плане написания не программистами). И три — я делал эксперимент: посадили мануальщика, сказали, что есть какое-то слово service и, если после него нажать точку, то будут подскази чего тут можно делать дальше. И парень сам написал тест без подсказок вообще. Так что вопрос спорный )
Давайте начнём дискуссию ) Я живу несколько в другом мире в контексте бдд. В нём не обязательно писать тесты на геркине, их можно писать и кодом. А суть в том, чтобы мыслить поведением, а не реализаций. На примере UI автоматизации логина реализацией будет loginPage.loginField.enterText('login');
loginPage.passwordField.enterText('password');
loginPage.loginButton.click();
Проблема здесь в том, что, если процедура логина поменяется, то править нужно будет большое количество тестов. С этим нам и помагает бдд: loginService.login('login', 'password');
Реализацией метода логин как раз и будет весь предыдущий код. Теперь изменения будут только в одном месте. Геркин тут не обязателен (а в моём мире ещё и нежелателен) ровно как и писать такие тесты до реализации кода, за что отвечает TDD подход. Миксовать их необязательно (но в моём мире желательно), т.к. они в принципе решают разные независимые друг от друга проблемы.
PS Я не утверждаю, что автоар не прав, но буду рад подискутировать, ибо в споре рождается истина.
TS, protractor и все остальные зависимости должны быть в package.json. Тогда после инстала можно будет запустить протрактор через npx, как я писал выше. А то, что что-то не работает — это хорошо ) Так мы учимся. Это к автору статьи. Что-то он не точно описал.
В статье typescript он поставил и локально и глобально. Поэтому tsc у вас должен работать. А вот протрактор в статье только локально. А на машине у него, видать, ещё и глобально стоит. Поэтому команда протрактора без npx у него работает, а у вас нет.
Протрактор — фреймворк, который запускает и ранит тесты. В конфиге для ноды мало что интересного есть )
Для дебага мало инфы, но есть подозрение, что у автора протрактор стоит глобально и тогда его команда работает. А у вас нет. Если вы делали в проекте
npm install protractor
то попробуйте команду
npx protractor output_js/config.js
npx поищет протрактор в папке node_modules внутри вашего проекта, ибо по дефолту всё ищется в глобальной директории.
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
Лучше ставить локально. На другйо машине версия может отличаться и всё пойдёт крахом )
Обычно принято заканчивать имя теста на *spec.js, но то не принципиально.
Особой разницы нет, просто мне привычнее работать с jar-файлом
Я бы не сказал, что особой разницы нет, т.к. webdriver-manager сам хендлит за вас работу с драйверами. Нет нужды искать какая версия драйвера соответствует новой версии браузера. Вебдрайвер-менеджер делает это за вас, посему является более предпочитетльным.
Если на проекте скучно, то можно, конечно, и руками )
Как для примера пойдёт, но explicit wait здесь лишний во всём тесте. Там и так всё достаточно быстро работает +, если я не ошибайюсь, то дефолтный implicit wait — пол секнды — подстрахует )
Это означает, что код не всегда выполняется в том порядке, в котором он написан.
Вот тут путаете ) Код всегда выполняется именно в том порядке, в котором он написан. Там ничего случайного нет. Разница в том когда вы получите результат асинхронного кода.
Здесь функция asyncChanger будет вызвана именно там, где она написана, но переменная изменится через секунду. Если инетерсно — могу дать пару ссылок с подробным разбором асинхронности в JS.
нам пригодится функция then()
Выше ж был код на async/await, а теперь обратно к промисам вернулись ) Можете запутать неопытного читателя. Промисы — это был прорыв в организации асинхронного кода, но async/await — следующий и более удобный шаг.
Он позволяет избегать promise hell, который раньше образовывался в коде из-за большого количества вложенностей
Тут не совсем точно. Промисы как раз позволили избавиться от callback hell. Но строить вложенности можно и на промисах. Таким страдают неопытные разработчики, особенно, которые долго сидели на колбеках.
Good:
Я начинал с питона и щас с удовольствием сижу на typescript. Но так для себя думаю, что питон для начала более выгодный язык. У js достаточно много подводных и не всегда очевидных вещейю А на гарвардском курсе SC50 вообще начинают с С. Что тоже есть весьма неплохо ибо понимаешь как оно всё устроено.
Я не говорю, что статья не имеет права на жизнь, но контент не соответствует названию (имхо, конечно же).
Единая точка входа — это, конечно хорошо, но только тогда когда тест кейсы написанные мануальщиком автоматически становятся авто тестами. Если их всё равно надо переписывать в авто тесты, то смысл пропадает. А именно так и происходит в 100% случаев, про которые я слышал и видел сам.
А сам кукмбер — это лишний слой абстракции, который накладывает значительные ограничания на архитектуру, которые надо как-то извращённо-костыльно решать.
loginPage.loginField.enterText('login');loginPage.passwordField.enterText('password');
loginPage.loginButton.click();
Проблема здесь в том, что, если процедура логина поменяется, то править нужно будет большое количество тестов. С этим нам и помагает бдд:
loginService.login('login', 'password');Реализацией метода логин как раз и будет весь предыдущий код. Теперь изменения будут только в одном месте. Геркин тут не обязателен (а в моём мире ещё и нежелателен) ровно как и писать такие тесты до реализации кода, за что отвечает TDD подход. Миксовать их необязательно (но в моём мире желательно), т.к. они в принципе решают разные независимые друг от друга проблемы.
PS Я не утверждаю, что автоар не прав, но буду рад подискутировать, ибо в споре рождается истина.
В статье typescript он поставил и локально и глобально. Поэтому tsc у вас должен работать. А вот протрактор в статье только локально. А на машине у него, видать, ещё и глобально стоит. Поэтому команда протрактора без npx у него работает, а у вас нет.
Для дебага мало инфы, но есть подозрение, что у автора протрактор стоит глобально и тогда его команда работает. А у вас нет. Если вы делали в проекте
то попробуйте команду
npx поищет протрактор в папке node_modules внутри вашего проекта, ибо по дефолту всё ищется в глобальной директории.
Больше про применение и подводные камни в автоматизации — www.youtube.com/watch?v=aY3KTwDp2zU
Если что — всегда рад помочь )
Это есть и в JS начиная с ES2015 (ES6).
А как же JS без этого живёт ) Разница в синтаксисе. TS — import, js стремится к тем же импортам, но изначально юзается require.
В JS нет типа данных int. Вместо него — number.
Не то, чтобы это было критично, но не рекомендуется использовать версии ноды с нечётной мажорной версией, ибо это бета версия для будущей LTS. Обычно нода предлагается в 2-ух версиях — LTS и Current. Последняя содержит новые фичи, но ещё не является окончательной. Но обе они имеют чётную мажорную версию. Например сейчас — 10.15.3 LTS и 12.3.0 Current.
Лучше ставить локально. На другйо машине версия может отличаться и всё пойдёт крахом )
я уже давненько не юзал протрактор, но по идее эта строчка уже лишняя. Почти год назад как контрол флоу должны были полностью убрать: https://github.com/SeleniumHQ/selenium/issues/2969
Обычно принято заканчивать имя теста на *spec.js, но то не принципиально.
Я бы не сказал, что особой разницы нет, т.к. webdriver-manager сам хендлит за вас работу с драйверами. Нет нужды искать какая версия драйвера соответствует новой версии браузера. Вебдрайвер-менеджер делает это за вас, посему является более предпочитетльным.
Если на проекте скучно, то можно, конечно, и руками )
Как для примера пойдёт, но explicit wait здесь лишний во всём тесте. Там и так всё достаточно быстро работает +, если я не ошибайюсь, то дефолтный implicit wait — пол секнды — подстрахует )
Вот тут путаете ) Код всегда выполняется именно в том порядке, в котором он написан. Там ничего случайного нет. Разница в том когда вы получите результат асинхронного кода.
Здесь функция asyncChanger будет вызвана именно там, где она написана, но переменная изменится через секунду. Если инетерсно — могу дать пару ссылок с подробным разбором асинхронности в JS.
Выше ж был код на async/await, а теперь обратно к промисам вернулись ) Можете запутать неопытного читателя. Промисы — это был прорыв в организации асинхронного кода, но async/await — следующий и более удобный шаг.
Тут не совсем точно. Промисы как раз позволили избавиться от callback hell. Но строить вложенности можно и на промисах. Таким страдают неопытные разработчики, особенно, которые долго сидели на колбеках.
Good:
Bad: