Сообщений в теме: 17

[Bond0608]

Здравствуйте, господа! Я начинаю заниматься автоматизированными тестами на angular 4. Мне нужно изучить связку сucumber и protractor. Посдкажите, пожалуйста, может есть какие-нибудь статьи на русском языке, где про это хорошо написано, может быть книги какие-нибудь есть?

[Spock]

почитать Баха, там хорошо объясняется почему не надо использовать кукумбер

 

всё что можно сделать на кукумбере - можно сделать просто на нормальном языке программирования, да ещё и в 3 раза быстрее

[Bond0608]

Мне нужна именно связка с кукумбером)

[Little_CJIOH]

почитать Баха, там хорошо объясняется почему не надо использовать кукумбер
 
всё что можно сделать на кукумбере - можно сделать просто на нормальном языке программирования, да ещё и в 3 раза быстрее

Если что-то предназначенное ускорить и облегчить некоторый процесс приводит к замедлению процесса в 3 раза, то вероятно или процесс у вас не тот, или готовите инструмент вы не правильно.
Cucumber - это тестовый фреймворк который жестко отделяет тесты от реализации, вводя для тестов отдельный "язык" близкий к натуральному, что позволяет получить дополнительный профит при правильном процессе с одной стороны, и отделить тест-дизайн от написания кода с другой, что тоже весьма не вредно.
Реализация же тестов в Cucumber выполняется на том самом "нормальном" языке программирования.
Если же вы собрались повторить функциональность кукумбера на "нормальном" языке программирования, то я сильно сомневаюсь что вы будете быстрее того, кто возьмет готовый инструмент.

[Little_CJIOH]

Мне нужна именно связка с кукумбером)

Связка кукумбера с протрактором - это код, который вы пишете ибо:
Кукумберу пофиг чем и как реализованы тесты которые он выполняет, он просто дергает методы и перекладывает данные
Протрактор - просто ручки к интерфейсу и ему все равно кто за эти ручки дергает, тем более что это будет не кукумбер, а некоторый написанный вами код.

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

[Little_CJIOH]

Нашел кстати высказывание Баха про Кукумбер:
"Vendors who want to sell me a tool that I can code up in Perl in a day. I don’t see the value of Cucumber. I don’t need FIT (although to his credit, the creator of FIT also doesn’t see the big deal of FIT). But if I did want something like that, it’s no big deal to write a tool in Perl. And both of those tools require that you write code, anyway. They are not tools that take coding out of our hands. So why not DIY?"

Я с ним абсолютно согласен концептуально. Но я не напишу кукумбер за день. И я ценю этот инструмент за явное разделение ролей тест-дизайнера и кодера + я участвовал в одном проекте на котором грамотное использование кукумбера дало бы существенный импрувмент тестирования даже в среднесрочной перспективе, и мои предположения не голословны, мне довелось общатся с людьми применившими аналогичный подход на аналогичном проекте и получившими ожидаемый мной профит.
А вот например charles proxy для меня треш. Потому, что я за день соберу инструмент который даст мне больше возможностей и без рюшечек, которых мне не надо.

И еще:
"I’m not opposed to such tools (although I continue to suspect that Cucumber is an elaborate ploy to spend a lot of time on things that don’t matter at all) but in the face of them we must keep a clear head about what testing is"

[Spock]

самая большая проблема в том, что люди неправильно понимают назначение тула и начинают писать интеграционные тесты на кукумбере

 

об этом говорят и сами разработчики кукумбера, что это самая большая ошибка пользователей, что Кукумбер подходит ТОЛЬКО для приёмочных тестов

[Little_CJIOH]

самая большая проблема в том, что люди неправильно понимают назначение тула и начинают писать интеграционные тесты на кукумбере
 
об этом говорят и сами разработчики кукумбера, что это самая большая ошибка пользователей, что Кукумбер подходит ТОЛЬКО для приёмочных тестов

Он подходит для высокоуровневых тестов.
Там может быть и приемочное и функциональное сложных бизнес систем. Например должник оператора связи со всеми его аккаунтами, линиями, графиками рассрочки, отложенными платежами, выставленными, оплаченными и неоплаченными счетами, услугами в виде java-объекта сущность совершенно непостижимая, а вот в gerkin его описывать одно удовольствие, прямо "дом, который построил Джек" получается.
Ну и стоит помнить, что BDD-фреймворк без BDD теряет некоторое количество своих плюшек.

[Spock]

 

 

Там может быть и приемочное и функциональное сложных бизнес систем. Например должник оператора связи со всеми его аккаунтами, линиями, графиками рассрочки, отложенными платежами, выставленными, оплаченными и неоплаченными счетами, услугами в виде java-объекта сущность совершенно непостижимая, а вот в gerkin его описывать одно удовольствие, прямо "дом, который построил Джек" получается.

это уже достаточно сложные тесты, и их много, так как тестирование уже функциональное

 

а когда много кукумберовских тестов - их очень сложно рефакторить, так как нет среды разработки с реальной полной поддержкой языка. есть в Intellij Idea поддержка, но достаточно базовая

 

рефакторинг будет по большей части ручной, поэтому большой набор тестов получится достаточно хрупким, и сложно будет его поддерживать, постоянно будешь бояться что в одном месте тронешь, а совершенно в другом месте сломается. получается рефакторинг "в 2 присеста" - отдельно рефакторишь обвязку на языке программирования и отдельно рефакторишь кукумберовскую часть с фича-файлами

[Little_CJIOH]

Там может быть и приемочное и функциональное сложных бизнес систем. Например должник оператора связи со всеми его аккаунтами, линиями, графиками рассрочки, отложенными платежами, выставленными, оплаченными и неоплаченными счетами, услугами в виде java-объекта сущность совершенно непостижимая, а вот в gerkin его описывать одно удовольствие, прямо "дом, который построил Джек" получается.

это уже достаточно сложные тесты, и их много, так как тестирование уже функциональное
 
а когда много кукумберовских тестов - их очень сложно рефакторить, так как нет среды разработки с реальной полной поддержкой языка. есть в Intellij Idea поддержка, но достаточно базовая
 
рефакторинг будет по большей части ручной, поэтому большой набор тестов получится достаточно хрупким, и сложно будет его поддерживать, постоянно будешь бояться что в одном месте тронешь, а совершенно в другом месте сломается. получается рефакторинг "в 2 присеста" - отдельно рефакторишь обвязку на языке программирования и отдельно рефакторишь кукумберовскую часть с фича-файлами

Если тесты нужно рефакторить - значит забили на аналитику, лишь бы побыстрее получить первый зеленый тест. Так кукумбер здесь ни при чем. Я первый раз этого добра хапнул в 1996 году, когда мы с другом игру на спектруме писали, сделали перемещение персонажа по горизонтали по 8 пикселей, чтоб быстрее прототип выпустить. Я потом переходя на 4 пикселя весь движок игры писал с нуля и редактор уровней.
В этом месте не важно какой у вас фреймворк. Важно понимать масштаб задачи и систему разрабатывать с поправкой на масштаб.
Кстати RubyMine имеет полноценную поддержку кукумбера, есть автокомплиты как минимум для Атома и Вим. + Если у вас столько тестов - можно уже и инструменты для обслуживания пописать.

[Spock]

 

 

Если тесты нужно рефакторить - значит забили на аналитику, лишь бы побыстрее получить первый зеленый тест. Так кукумбер здесь ни при чем. 

ну рефакторинг это нормальный процесс разработки, постоянно ведь что-то меняется, нельзя ведь всё сразу прекрасно написать

 

 

 

В этом месте не важно какой у вас фреймворк

тут вопрос, либо у тебя один фреймворк, написанный на языке программирования - либо 2 фреймворка, один поверху другого

 

 

 

Кстати RubyMine имеет полноценную поддержку кукумбера

всё равно ведь получается 2 фреймворка, и разработка этим значительно усложняется. ведь изменения в руби не передадутся волшебным образом в кукумбер

[Bond0608]

Я написал вот такую feature 

Feature: LoginFeature
    This feature deals with the login functionality of the application

    Scenario: Login with correct e-mail and password
        Given I navigate to the login page
        And I enter the e-mail as m@mail.ru and password as 111111
        And I click login button
        Then I should see the GameScenarioPage

И step_definitions

import {defineSupportCode} from 'cucumber';
import {browser, element, by} from 'protractor';

defineSupportCode(consumer => {
    consumer.When(/^I navigate to the login page$/, () => {
        return browser.get('/login');
    });
    consumer.When(/^I enter the e\-mail as m@mail\.ru and password as (\d+)$/, function (email, password) {
        var inputEmail = element(by.model('email'));
        var inputPassword = element(by.model('password'));
        inputEmail.sendKeys('m.@mail.ru');
        inputPassword.sendKeys('111111');
    });
    consumer.When(/^I click login button$/, function (inputEmail, inputPassword) {
        element(by.partialButtonText('Регистрация')).click();
    });
    consumer.When(/^I should see the GameScenarioPage$/, () => {
        return browser.get('/users');
    })
});

Мне выдало такую ошибку, как я могу её исправить? Подскажите, пожалуйста

https://prnt.sc/fzyn6e

Сообщение отредактировал Bond0608: 25 июля 2017 - 08:45

[Little_CJIOH]

Если тесты нужно рефакторить - значит забили на аналитику, лишь бы побыстрее получить первый зеленый тест. Так кукумбер здесь ни при чем. 

ну рефакторинг это нормальный процесс разработки, постоянно ведь что-то меняется, нельзя ведь всё сразу прекрасно написать

Это нормально, когда никто не знает что должно получится в результате, но в продакшен надо вчера. Но даже в такой ситуации, если вам больно при рефакторинге - значит код - говно. Код с хорошей архитектурой рефакторится без особых проблем.
 

В этом месте не важно какой у вас фреймворк

тут вопрос, либо у тебя один фреймворк, написанный на языке программирования - либо 2 фреймворка, один поверху другого

Если у вас 2 фреймворка, один поверх другого, то кто-то гнусный извращенец, или у кого-то смысл термина фреймворк уплыл.
 

Кстати RubyMine имеет полноценную поддержку кукумбера

всё равно ведь получается 2 фреймворка, и разработка этим значительно усложняется. ведь изменения в руби не передадутся волшебным образом в кукумбер

У меня не получается. Изменения в руби-коде не должны передаваться в джеркин-код. Это разные уровни абстракций один описывает тесты, другой реализацию шагов тестов.
И давайте уточним, что такое "фреймворк"?

[Bond0608]

Я написал вот такую feature 

Feature: LoginFeature
    This feature deals with the login functionality of the application

    Scenario: Login with correct e-mail and password
        Given I navigate to the login page
        And I enter the e-mail as m@mail.ru and password as 111111
        And I click login button
        Then I should see the GameScenarioPage

И step_definitions

import {defineSupportCode} from 'cucumber';
import {browser, element, by} from 'protractor';

defineSupportCode(consumer => {
    consumer.When(/^I navigate to the login page$/, () => {
        return browser.get('/login');
    });
    consumer.When(/^I enter the e\-mail as m@mail\.ru and password as (\d+)$/, function (email, password) {
        var inputEmail = element(by.model('email'));
        var inputPassword = element(by.model('password'));
        inputEmail.sendKeys('m.@mail.ru');
        inputPassword.sendKeys('111111');
    });
    consumer.When(/^I click login button$/, function (inputEmail, inputPassword) {
        element(by.partialButtonText('Регистрация')).click();
    });
    consumer.When(/^I should see the GameScenarioPage$/, () => {
        return browser.get('/users');
    })
});

Мне выдало такую ошибку, как я могу её исправить? Подскажите, пожалуйста

https://prnt.sc/fzyn6e

[Spock]

 

Код с хорошей архитектурой рефакторится без особых проблем.

Ну давайте сравним кто “рефакторится без проблем”:

 

У кого тесты например на джаве - да, рефакторятся без проблем. А у кого тесты на кукумбер+джава - им приходится попотеть, рефакторя сразу и там и там, делая двойную работу

 

 

 

если вам больно при рефакторинге - значит код - говно

вот при связке джавы и кукумбера будет больно делать двойную работу

[Little_CJIOH]

Код с хорошей архитектурой рефакторится без особых проблем.

Ну давайте сравним кто “рефакторится без проблем”:
 
У кого тесты например на джаве - да, рефакторятся без проблем. А у кого тесты на кукумбер+джава - им приходится попотеть, рефакторя сразу и там и там, делая двойную работу
 

если вам больно при рефакторинге - значит код - говно

вот при связке джавы и кукумбера будет больно делать двойную работу

Без проблем рефакторится тот, кто думал головой при написании кода, не важно на чем.
Если рефакторить надо тесты, то либо происходит рефакторинг проекта, например из интернет-магазина в интернет-банк, хотя лично я такого не видел ни разу, либо при написании тестов голову не включали вообще, то есть структура тестов не соответствует структуре приложения.
Есть еще один вариант когда тесты надо рефакторить, когда они писаны сплошным кодом, без отделения тестов от имплементации. Этого кстати, с кукумбером достичь гораздо сложнее, чем с TеstNG (давайте будем исходить из того, что "Тесты на джаве" - это фреймворк TestNG)
И я категорически отказываюсь понимать в чем состоит двойная работа при работе с кукумбером. То что в "тестах на джаве" тесты и имплементация свалены в одну кучу дает не ускорение работы, а больше возможностей написать нечитаемые тесты с высокой связностью кода, которые как раз обычно чешутся и просятся в рефакторинг.

Мой опыт поддержки тестов писанных на кукумбере говорит что они не требуют больших затрат на поддержку. Под моими тестами дважды менялся API тестируемой системы без изменения функциональности. Мне не пришлось делать ни одного изменения в gherkin-части.

[Spock]

 

 

 в "тестах на джаве" тесты и имплементация свалены в одну кучу

свалены только у того кто пишет криво. в нормальных проектах тесты и имплементация пишется в разных классах-модулях

 

 

 

Мой опыт поддержки тестов писанных на кукумбере говорит что они не требуют больших затрат на поддержку. Под моими тестами дважды менялся API тестируемой системы без изменения функциональности. Мне не пришлось делать ни одного изменения в gherkin-части. 

потому что был рефакторинг только "движка" на нормальном языке программирования - а это конечно же делается просто. оттуда и ощущение что "всё просто"

 

вот кому достанется рефакторить сами геркиновские тесты + "прослойку" которая транслирует "человеческий язык" в вызовы методов - получит головную боль, например:

хочешь в геркине экстрактировать несколько строчек кода в отдельный метод? нет такой функции, да и много чего нет, нет многих "помогаторов" которые есть в ИДЕ для обычных языков программирования

хочешь вызвать метод из движка? не так просто! пожалуйста напиши тут же и "прослойку-переводчик", сделай двойную работу

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

хочешь в геркине сделать "code re-use" и использовать шаги с другого теста используя инклюд? ну практически смертный приговор себе подписал!

 

а про рефакторинг который имею ввиду, не "тотальный", когда всё криво - а повседневный, типа переименовать метод и переменную, добавить-убрать параметры из метода, поменять тип параметра, экстрактить строчки в метод, обернуть в цикл или условие и тому подобные простые таски

[Little_CJIOH]

 в "тестах на джаве" тесты и имплементация свалены в одну кучу

свалены только у того кто пишет криво. в нормальных проектах тесты и имплементация пишется в разных классах-модулях
 

Мой опыт поддержки тестов писанных на кукумбере говорит что они не требуют больших затрат на поддержку. Под моими тестами дважды менялся API тестируемой системы без изменения функциональности. Мне не пришлось делать ни одного изменения в gherkin-части. 

потому что был рефакторинг только "движка" на нормальном языке программирования - а это конечно же делается просто. оттуда и ощущение что "всё просто"
 
вот кому достанется рефакторить сами геркиновские тесты + "прослойку" которая транслирует "человеческий язык" в вызовы методов - получит головную боль, например:
хочешь в геркине экстрактировать несколько строчек кода в отдельный метод? нет такой функции, да и много чего нет, нет многих "помогаторов" которые есть в ИДЕ для обычных языков программирования
хочешь вызвать метод из движка? не так просто! пожалуйста напиши тут же и "прослойку-переводчик", сделай двойную работу
хочешь добавить условие или цикл в геркинский тест? ой, головная боль!
хочешь в геркине сделать "code re-use" и использовать шаги с другого теста используя инклюд? ну практически смертный приговор себе подписал!
 
а про рефакторинг который имею ввиду, не "тотальный", когда всё криво - а повседневный, типа переименовать метод и переменную, добавить-убрать параметры из метода, поменять тип параметра, экстрактить строчки в метод, обернуть в цикл или условие и тому подобные простые таски

Почему разделение тестов и имплементации дает двойную работу в кукумбере и не дает ее в "джаве"?
"прослойка которая транслирует человеческий язык в вызовы методов" называется Cucumber и ее ни писать, ни рефакторить не надо.
"хочешь в геркине экстрактировать несколько строчек кода в отдельный метод? нет такой функции" Да, функция которая выделяет несколько того чего нет в то чего нет не существует. Нет в геркине ни строк кода ни методов. Циклов и условий тоже нет, потому что, если у тебя в тестовом сценарии условие, значит у тебя два тестовых сценария, а если цикл, то значит имплементация вылезла из под капота и пора запихать ее обратно.
А за дерганье какого-нибудь "селениума" непосредственно из сценария, минуя все "прослойки", нужно сжигать на месте, потому, что это называется код с высокой связностью, и очень больно в поддержке.
Code reuse в gherkin делается на раз-два-три без всяких инклюдов. Все степ-дефинишены доступны из всех фиче-файлов в рамках одного проекта.

Наш спор бессмысленен. Ваши аргументы про попытку применять Cucumber не просто без BDD, но еще и без сценариев.