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

[Spock]

 

 

Я не спорю, что разработчиков можно заставить и кофе приносить. Но с тем, что это нормально, не соглашусь. 

в Гугле например все разработчики пишут и тесты(и юнит и интеграционные, и е2е), и фреймворки - и это там считается нормальная практика. Ведь девы - это те люди, которые лучше всего знают код

[Spock]

 

 

Пишется для кода внешний API и хоть из баша курлами его дергайте 

тот АПИАЙ и был внешний, только зашифрованный - вот я его и тестировал

 

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

[baxatob]

 

в Гугле например все разработчики пишут и тесты(и юнит и интеграционные, и е2е), и фреймворки - и это там считается нормальная практика. Ведь девы - это те люди, которые лучше всего знают код

 

 

Не работал в Гугле, не знаю, как оно там на самом деле. На нашем проекте в среднем почасовая ставка разработчика в 1,2 - 1,3 раза выше ставки автоматизатора тестов аналогичного уровня. И уже только поэтому никому в голову не придет использовать разработчика для автоматизации Е2Е тестов. 

[Spock]

 

 

Не работал в Гугле, не знаю, как оно там на самом деле. На нашем проекте в среднем почасовая ставка разработчика в 1,2 - 1,3 раза выше ставки автоматизатора тестов аналогичного уровня. И уже только поэтому никому в голову не придет использовать разработчика для автоматизации Е2Е тестов. 

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

 

пример в е2е тестировании с Селениумом:

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

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

 

тесты будет писать тестировщик

 

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

[baxatob]

А отвечать кто за все это будет? Сисадмин?

[Spock]

 

 

А отвечать кто за все это будет? Сисадмин?

отвечать за качество будут все

 

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

 

качество продукта улучшается

[baxatob]

 

отвечать за качество будут все

 

Это только в теории хорошо звучит.

А на практике - у семи нянек дитё без глазу.

 

 

 

 

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

 

С этим трудно не согласиться. Однако это не значит, что программист должен писать за тестировщика хоть часть теста, если только на проекте не стоит задача, сделать жизнь тестировщика сладкой и кайфовой :-D

[Spock]

 

Это только в теории хорошо звучит.

А на практике - у семи нянек дитё без глазу.

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

 

 

 

С этим трудно не согласиться. Однако это не значит, что программист должен писать за тестировщика хоть часть теста, если только на проекте не стоит задача, сделать жизнь тестировщика сладкой и кайфовой :-D

иногда программисты пишут тесты для покрытия, когда сами находят и сами фиксят свои баги. не всегда программисты бегут к тестеру, чтобы он написал тест для бага который сам дев нашёл и сам поправил

[Сергей]

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

 

Опрос явно был бы продуктивнее, кто что использует.

[Spock]

да уже вроде выяснилось что надо использовать чисто программные средства, никаких Постманов и других UI tools

и что даже выбор языка иногда не так и важен

 

а так да, оффтоп небольшой уже пошёл

[catrun]

Мы использовали Python+Suds

[baxatob]

Мы использовали Python+Suds

 

suds это все же soap-клиент. Для rest-сервисов лучше библиотеку requests подключить.

[Belerafon]

Мы используем Java+JUnit+RestAssured. Все интегрировано в CI, тесты запускаются при каждом merge в главную ветку. 

Почему выбрали именно это - 

• Java - основная разработка ведется на Java, я как лид тестер комфортнее всего себя чувствую именно с Java, в компании есть бесплатные курсы Java, на которые ходят другие тестеры.
• JUnit - нет смысла расписывать, по желанию можно заменить на TestNG. Других алтернатива не знаю.
• RestAssured - позволяет отсылать HTTP запросы, легко парсить ответы. Код получается краткий, читабельный - я думаю это наиболее веский довод "ЗА". Не принципиально REST у вас или не REST (как у нас). Из коробки позволяет делать soft asserts, в нашей реальности это полезно.

Из недостатков могу сразу вспомнить то, что если по каким-то причинам ваш сервис присылает ответы в HTML формате, парсить такой ответ средствами RestAssured будет сложно - HTML часто содержит не закрытые теги и из-за этого возникают проблемы. Придется использовать сторонние библиотеки. С XML и JSON справляется отлично.

[SergeyQA]

Коллеги, всем привет! Дабы не плодиться темами, напишу сюда свой вопрос, ибо тема вроде подходит)
Пишу автотесты для API мобильного приложения на Питоне.
Не было проблем ни с одним из методов, пока дело не дошло до метода PUT.
Всю голову поломал, все наверно перепробовал. К сути.
Есть метод добавления товара в корзину. В постмене все работает замечательно. 
Как верно написать метод на питоне с помощью библиотеки requests (ну или другой).

Вот моя функция.

 

    def add_product_to_cart(self, product_id):
        url = 'url_method/' + str(product_id)
        headers = {"access_token": access_token}
        body= {"qty": 1} #кол-во добавляемых товаров

        r = requests.put(url, data=body, headers=headers).json()
        print(r)

В разных вариациях запроса, играясь с headers и body, в ответе я получаю две вещи: либо исключение, что ожидается json, но в ответе не json (действительно, ответ приходит в виде html), либо то, что не  получен авторизационный токен (этот ответ приходит в формате json).
Уточню, что body нужно передавать в виде x-www-form-urlencoded
Пример запроса в постмане (к сожалению не могу все показать, попаду под неразглашение) 
http://joxi.ru/xAeBRKMtppQwKr
 http://joxi.ru/brRKk9ZcJJjXem
Как правильно написать код, чтобы токен все же передался? 
Подскажите, пожалуйста! 

 

[MissLeman]

Здравствуйте.

 

Есть набор автоматических Jasmine + Protractor, запускаемые автоматически через TeamCity с выпуском каждого билда. Возникла необходимость в этот набор включить немного относительно простых тестов rest api (типа: послал запрос, проанализировал ответ). Сейчас надо это реализовать достаточно быстро, можно на уровне "лишь бы работало".

 

Вопрос: можно ли включить проверки запросов в вышеупомянутый уже существующий набор через что-то типа AJAX + какое-то решение кроссдоменности? Или можно (и нужно) как-то попроще?

 

(я понимаю, что вопрос несколько идиотский, но уж задам его в том виде, как он есть).

[Spock]

например

 

https://github.com/vlucas/frisby

[MissLeman]

например

 

https://github.com/vlucas/frisby

Вещь! Спасибо огромное.