Comments 8
Советую поглядеть в сторону feign(okhttp3 в кач-ве клиента) + jackson в качестве decoder/encoder.
Ресташшурд тащит рантайм груви и выжирает 1-2гб оперативы, feign же — jaxrs-наоборот и является более простой и удобной вариацией Retrofit. Жрет мало ресов, шустрый, умеет в дженерики через наследование интерфейса, нет многословности с чейнингом, в общем, тестирование АПИ с ним весьма упрощается.
Можно подробнее кейс? Если это касается сериализации, то ObjectMapper Jackson'a имеет настройки пропускать или включать null, правда не связывался с ним в Ресташшурде.
Ресташшурд тащит рантайм груви и выжирает 1-2гб оперативы, feign же — jaxrs-наоборот и является более простой и удобной вариацией Retrofit. Жрет мало ресов, шустрый, умеет в дженерики через наследование интерфейса, нет многословности с чейнингом, в общем, тестирование АПИ с ним весьма упрощается.
Самое сложное и неочевидное, с чем мне довелось столкнуться в данным подходе, это невозможность передать в Rest-Assured в качестве одного из параметров null (результат — падение в NullPointerException).
Можно подробнее кейс? Если это касается сериализации, то ObjectMapper Jackson'a имеет настройки пропускать или включать null, правда не связывался с ним в Ресташшурде.
Суть проблемы с null была не на этапе десериализации Jackson'ом, а в момент вызова API: Rest-Assured просто не давал отправить null. Судя по этому issue (https://github.com/rest-assured/rest-assured/issues/942), сталкивался с данной проблемой не только я.
Если честно, это дичь какая-то)
Во-первых, по оформлению — код скринами, нет примеров самих тестов.
Во-вторых, почему бы не сделать нормальные модели данных, а не эти ужасные классы BasePojo? Json файл можно очень быстро перегнать в класс Java с помощью плагина для IDE, и потом сделать нужные конструкторы или билдеры для формирования тестовых данных.
В-третьих, вы Rest-Assured используете только для отправки запроса и десериализации? Это как их пушки по воробьям, имхо. Проще взять http-клиент и тот же Jackson, а не тащить «толстый» Rest-Assured, как правильно заметили в предыдущем комменте.
В любом случае, опыт, конечно интересный. Но мне кажется, что выводы у вас неверные по результатам эксперимента.
Во-первых, по оформлению — код скринами, нет примеров самих тестов.
Во-вторых, почему бы не сделать нормальные модели данных, а не эти ужасные классы BasePojo? Json файл можно очень быстро перегнать в класс Java с помощью плагина для IDE, и потом сделать нужные конструкторы или билдеры для формирования тестовых данных.
В-третьих, вы Rest-Assured используете только для отправки запроса и десериализации? Это как их пушки по воробьям, имхо. Проще взять http-клиент и тот же Jackson, а не тащить «толстый» Rest-Assured, как правильно заметили в предыдущем комменте.
В любом случае, опыт, конечно интересный. Но мне кажется, что выводы у вас неверные по результатам эксперимента.
Отвечу по пунктам.
Во-первых, проект у нас под NDA, соответственно никаких живых примеров за рамками приведенных скриншотов я показать не могу. Скрины — лишь иллюстрация подхода, но не готовые модули для использования в своих проектах. Поэтому и в код их переводить не имеет смысла.
Во-вторых, мы рассматривали вариант хранения статичных данных в JSON-ах на этапе выбора подхода, но предпочли генерировать все на лету, а не держать коллекции. На мой взгляд, это вопрос личных предпочтений.
В-третьих, мы отталкивались от собственного удобства в рамках условий конкретного проекта.
Во-первых, проект у нас под NDA, соответственно никаких живых примеров за рамками приведенных скриншотов я показать не могу. Скрины — лишь иллюстрация подхода, но не готовые модули для использования в своих проектах. Поэтому и в код их переводить не имеет смысла.
Во-вторых, мы рассматривали вариант хранения статичных данных в JSON-ах на этапе выбора подхода, но предпочли генерировать все на лету, а не держать коллекции. На мой взгляд, это вопрос личных предпочтений.
В-третьих, мы отталкивались от собственного удобства в рамках условий конкретного проекта.
мы рассматривали вариант хранения статичных данных в JSON-ахЯ не про это. А про то, чтобы сделать обычные классы Java согласно модели данных передаваемых сообщений.
public class Campaign {
@JsonProperty("id")
private int id;
// etc...
}И добавить конструкторы или билдеры, для «генерировать все на лету». Это было бы удобнее читать и править при необходимости.
мы отталкивались от собственного удобства в рамках условий конкретного проектапро это бы написали. Какие еще рассматривали инструменты (кроме, разумеется, RF), почему не подошли.
1. В этом месте читаемостью немного пренебрегли в угоду гибкости и скорости составления входных объектов, как это делают, например, создатели гоночных болидов… Они не ставят внутрь кондиционер, хотя на треке жарко.
2. Никакой масштабной оценки «всех инструментов на рынке», понятно, не было. Мы взяли первый же вариант, который подошел под требования и наши ожидания.
2. Никакой масштабной оценки «всех инструментов на рынке», понятно, не было. Мы взяли первый же вариант, который подошел под требования и наши ожидания.
1. В этом месте читаемостью немного пренебрегли в угоду гибкости и скорости составления входных объектов, как это делают, например, создатели гоночных болидов… Они не ставят внутрь кондиционер, хотя на треке жарко.
Неуместная аналогия, вы наполняете объекты прям в тесте, вместо того, чтобы эту логику инкапсулировать. Это помогло бы избежать последующих копипастов и лишило бы проблем с поддержкой тестов.
2. Никакой масштабной оценки «всех инструментов на рынке», понятно, не было. Мы взяли первый же вариант, который подошел под требования и наши ожидания.
…
по итогам освоения подхода записали его в список ключевых для подобного рода задач.
Получается, вы выбрали ключевым(!!) инструментом продукт, на основе только лишь желания попробовать что-то новое(«первый же вариант»).
Sign up to leave a comment.
Практика тестирования бэкенда на Java + Rest-Assured