Могу ли я вызывать разные тесты TestNG, изменяя тестовые данные?

ИСТОРИЯ: У меня есть REST API, которые я тестирую с помощью Rest Assured. Я использую TestNG для выполнения тестов. Однако ответы API различаются для разных значений заголовка запроса Accept (application / xml OR application / json). Например, - теги, присутствующие в ответе xml, отображаются с разными ключами, например, появляется "employeeNo".

Поэтому мне нужно написать 2 разных теста (утверждения и синтаксический анализ) - один для ответа xml, а другой для ответа json, все остальное остается прежним. Например, - updateEmployeeNameJsonTestSuite и updateEmployeeNameXmlTestSuite.

ТЕКУЩИЙ ПОДХОД: у меня есть два разных файла тестовых данных и два разных набора тестов - один для ответов json и один для ответов xml, каждый из которых вызывается с использованием параметра -suiteName, предоставляемого TestNG.

ПРОБЛЕМА: я хочу параметризовать значение Accept Request Header в файле тестовых данных, а затем TestNG программно решить, какой тест вызывать. Мне не удалось найти хороший подход для достижения этой цели программно. Какие-либо предложения ?


testng rest-assured
person user2611581    schedule 24.12.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Почему бы вам не параметризовать свой тест и не передать тип ответа в качестве параметра в testng xml. А затем, в зависимости от этого параметра, вы можете создать заголовок запроса. Мы делаем то же самое для тестирования нашего веб-сервиса. И снова напишите общий метод для проверки, который будет определять, какой тип ответа будет в зависимости от значения параметра.

<suite name="My suite">
  <parameter name="ResponseType"  value="Json"/>
  <test name="Simple example">
  <-- ... -->




 @Parameters("ResponseType")
    @Test
    public void testNonExistentParameter(@Optional("xml") String ResponseType) { 
// Use Response type
}

То же самое можно сделать для методов @before

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

person Shamik    schedule 24.12.2014
comment
Хотя в конечном итоге я использовал @DataProviders, это определенно помогло мне в правильном направлении. - person user2611581; 07.01.2015