да

для него сета нет

но если в масиве

метод сет есть

и если искать через find тогда селектор такой ненайдет

Ещё раз. Ошибка > method set undefined Говорит нам о том, что у элемента, который лежит в массиве под индексом [0] нет такого метода.

вот вам ангуляровская форма

Значит надо смотреть, что за элемент там лежит, и, вероятно, или искать нужный вместо того, что находится, или использовать другой метод. :)

Дебажить, дебажить и ещё раз дебажить.

ты имеешь ввиду ("input[name='email']", :match => :first)

Я имею ввиду посмотреть, для начала, что тебе приходит в ответе page.all("input[name='email']")[0]

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

в вебките например все ок с [0]

дело не в том, КАК ты написал код

дело в том, что Shoo говорит, что на всяких null объектах едвали set метод есть

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

ооо

а я сейчас посмотрю

undefined method `set' for #<Capybara::Result:0x007fc438a6bb80>

http://www.rubydoc.info/github/jnicklas/capybara/master/Capybara/Result

сейчас пошуршим

Народ! А нет ли у кого электронного варианта книги "закон малинового варенья" ?

коллеги, а насколько кошерно при написании автотестов для API, использовать это же API для напсания тестов, например: необходимо протестировать метод API для удаления записи. Перед этим запись надо создать, правильно ли для создания записи использовать метод API, а затем, другим методом удалять эту запись.

Тесты должны быть атомарны, т.е нужно разделить и тестировать каждый метод отдельно. Можно, конечно прогонять самые длинные пути прохождения данных, но это уже перед выпуском. А в данном случае, нужно разделить, ибо это два разных кейса.

вот, я так и думал, спасибо

Ну, при этом prepare statement с использованием апи - это нормально, но тест на создание юзера это не исключает.

если ты тестируешь API, и, например, метод DELETE сущности, то нет ничего плохого в том, что этот же POST метод будет создавать сущность. В этом случае есть 2 подхода: 1) Вы компенсируете наполненость данными за счет того, что где-то у вас есть тест на создание объекта. А в тесте на удаление вы случайно получаете какой-то объект, который будете удалять. 2) Вы непосредственно перед тестом в дата-провайдере создаете объект через API, и сразу же его удаляете.

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

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

Вариант "передавать данные из другого теста" плох тем, что добавляет лишнего рандома в тестируемой сущности.

передавать данные это боль, не надо так

"добавляет лишнего рандома в тестируемой сущности" - например? На прошлом месте работы у нас был датапровайдер, который мог для слоя DB или API запрашивать для теста сущность типа: Db().User().withStatus(1).hasFollowers(1).hasFollowings(1).withAlias('Mordor').getRandomRow() или Api().Firm().getFirm().withFilialID('123445678').getRandomRow() т.е. такая ORM и API с гарантировали, что по заданному критерию будет находиться случайная сущность с запрошенными данными + такая сущность будет на сессию (запуск тестов из консоли, один процесс) будет исключать эту сущность из выборок, чтобы исключить неконсистетность тестов при параллельном запуске и рейс-кондишенах.

"добавляет лишнего рандома в тестируемой сущности" - например? На прошлом месте работы у нас был датапровайдер, который мог для слоя DB или API запрашивать для теста сущность типа: Db().User().withStatus(1).hasFollowers(1).hasFollowings(1).withAlias('Mordor').getRandomRow() или Api().Firm().getFirm().withFilialID('123445678').getRandomRow() т.е. такая ORM и API с гарантировали, что по заданному критерию будет находиться случайная сущность с запрошенными данными + такая сущность будет на сессию (запуск тестов из консоли, один процесс) будет исключать эту сущность из выборок, чтобы исключить неконсистетность тестов при параллельном запуске и рейс-кондишенах.

Ну, если у тебя тест упал с данными, которые ты специально для него приготовил - у тебя два варианта: либо тест не актуален, либо баг.

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

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

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

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

А зачем это? Можно избежать такой ситуации, просто используя готовые, независимые данные.

логи, ребята, в логах всё есть :) берешь потом и в Postman проверяешь. А захардкоженные данные плохи тем, что ты не можешь на 100% быть уверен, что в результате тестирование и мейнтенанса, при доступе несолкьих QA к одной БД - поведение и ожидаемый набор тестовый не перестанет быть чем-то, чем ты хотел чтоб он был изначально

ключевое слово "независимые" - в реальности это не всегда так

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

Ничего не мешает.

Это тратит время.

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

короче , что то у меня невыходит никак

Тесты всегда должны выполняться в условиях полной ясности, иначе результат тестирования не репрезентативен.

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

Зато шанс, что придётся дебажить - гараздо меньше

Тесты всегда должны выполняться в условиях полной ясности, иначе результат тестирования не репрезентативен.

абсолютно репрезентативен

https://www.slideshare.net/VLDCORP/rest-api-49205514

посмотрите кому интересно

Брать рандомные данные то же самое, что запускать тесты в рандомной версии рандомного браузера.

Работает, но при падении сложнее отдебажить проблему.

нет

Да.

если ты незнаешь свои тесты тогда тебе и дебажить тяжело

сделай дебаг нормальный и все будешь понимать

если ты незнаешь свои тесты тогда тебе и дебажить тяжело

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

у меня рандомные условия и я сделал дебаг на каком условии оно падает

сделал метки и путсы

ребят

чет я совсем скис, никак не ищет метод find селектор

как будто его нет

я аж завис

@azshoo посмотри все же слайдики :) если лень, то особенность такого полхода в том, что требования к данным: - реальные - случайные, но однородные - уникальные

особенность реста - он не должен работать для одного сета, он должен работать на многих :) за счет однородных, но уникальных данных мы нашли баги, которые не нашлись никогда бы за счет хардкода

на миллионе пользователей, миллионах их данных - ты бы не попал на такие кейсы в принципе.

@azshoo посмотри все же слайдики :) если лень, то особенность такого полхода в том, что требования к данным: - реальные - случайные, но однородные - уникальные

Я видел слайдики, да, и на тех же SQA days раз в год мелькают выступления о том, почему рандом это плохо.

ERROR: S client not available

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

рандом плохо, когда твои данные не отображают твою ментальную модель для тестирования, т.е. твой сценарий например "пользователь с 100 отзывами (появляется расчет рейтинга, floating statistics) и больше чем 1 отзывом к одному предприятию (2 отзыва не считаются в статистике, считается последний) - вот это - твоя тестовая модель. Ей должно быть по барабану, кто это будет из тысячи пользователей

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

время на воспроизведение: 10 секунд. Время на дебаг с этого шага ничем не отличается от любых хардкод данных. Логирование тестов тут вообще не причем.

printf пофигу, хардкод или случайные данные в датапровайдере выводить :)

Так. Ещё раз. Если у тебя есть заранее готовая тестовая модель (чистая), то у тебя есть два варианта падения - неактуальный тест или баг. Если у тебя модель dirty - таких вариантов больше по умолчанию.

Больше вариантов -> дольше дебажить. Довольно очевидно, нет?

И это, к слову говоря, мы говорим о false negative сценарии. false positive за счёт кривых данных тоже никто не отменял.

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

Истории с миллионами пользователей и миллионами данных, и багами которые это плодит нужно решать по другому.

Больше вариантов -> дольше дебажить. Довольно очевидно, нет?

нет, для случая описанного мной - это не проблема. "Вот рандом в данных - это "пошли что-нибудь". и опять это не тот случай. в таком подходе используются набившие всем оскомину классы эквивалентности и граничные значения. Данные случайны в пределах корректности. Например, ты тестируешь форму, и в ней нельзя писать 5 символов подряд. Ты на своем кейсе проверяешь хардкод из 'aaaaa', метод, который лучше - проверить, что это будет работать всегда на любом asci символе. "Тестовые данные - это всегда прозрачная модель" воистину, и это не перечит тому, что запрашивая данные под конкретный кейс мы получаем прозрачные данные :) QA не приходится зашиваться на юзера, на котором работет тест и он зеленый, появляется уверенность, что так работает со всем набором юзеров :)

Нет, не появляется.

Появляется только уверенность, что на рандомном юзере это работает, и всё.

как часто вы тестируете на бою? или у вас дампы базы данных? А что если пользователь на котором вы тестируете, удалится? "но я тестирую на созданных данных только для теста, никто их не трогает, кроме меня!" - но тогда это не реальные данные, и это совсем другая история.

Я готовлю тестового пользователя специально для теста.

Нету никакого тестовго пользователя X

Это обычный prepare statement. Есть тест, начинающийся с определенного шага - есть фабрика, которая готовит соответствующее состояние системы.

И нет, я не гоняю автотесты на боевых серверах (а зачем?), только дампы продакшена и production-like окружение.

ребят, я по поводу прошлой проблеме

есть метод find

xpath and css селекторы не находит

а методом page.all не сетит

напомню selenium => capybara => ruby

грустно это :(

да капец

вот два вопроса меня мучают целое утро

проверка на загрузку ангуляра на странице

и заполнение в самом селениуме

Посмотри как это сделано в protractor и скопипасть.

и заполнение в самом селениуме

Я бы на твоем месте попробовал проделать то же самое силами голого селениума (без капибары) и посмотрел на результат.

да