Безусловно, интеграционными тестами мы также можем закрыть эту задачу.
У меня следующий довод: такой «юнит» дешевле чем интеграционный тест, в добавок ниже всех в иерархии, а значит первым отвалится, если что не так. То есть быстрее укажет на ошибку.
Тут важно добавить контекста- тестировщиков меньше чем разработчиков, поэтому в данном конкретном случае разработка такими тестами заранее снимает часть вопросов, которые могут возникнуть в дальнейшем, т.е. в какой-то степени разгружает тестирование.
Такие тесты (@JsonTest) проверяют корректность настройки Jackson’а, которую мы реализуем в соответствии с контрактом.
Пример: Мы описываем DTO, настраиваем: * форматы дат (@JsonFormat); * имена полей (@JsonProperty); * алиасы (@JsonAlias) также иногда настраиваем для десериализации; * DTO может использовать ENUM’ы, которые сериализуются не “as-is”, а, к примеру MALE/FEMALE должны в итоге выглядеть как мужской/женский и т.п (@JsonValue).
Когда мы все это настроили, то проверяем, что результат соответствует требуемому (согласно постановке/договоренностям) контракту. То есть результат сериализации мы сравниваем с эталонным JSON, который рассчитываем получить, а десериализации - с объектом, который из него собирается.
мне очень интересно, как вы убедили разработчиков, что такие тесты нужны
Так как я и есть один из разработчиков - меня даже и убеждать не пришлось :). На самом деле просто слишком высока цена ошибки. Ведь API внешний, им пользуются много потребителей. Они разрабатывают своё ПО для интеграции с нами. Стоит что-то пропустить и затем либо вечно об этом помнить, чтобы никому ничего не сломать, либо долгая процедура - договориться с потребителями. Оба пути неприятные - костыли либо репутационные риски. Поэтому пока тест не написал, считай - не проверил.
Да и в любом случае, скорее всего геттеры и сеттеры покрываются какими-то соседними тестами.
Полностью согласен, покрываются соседними тестами, статический анализатор может пропустить. Да, как Вы верно сказали, остается code review.
Задача, которую он решает, хоть и возникла в моей организации, но все же не является специфической конкретно для нее. Поэтому он может быть применен не только там где я работаю. А если он может быть полезен где-то еще, то стоит опубликовать. Я так размышлял.
Вариант не рассматривал, но суть вопроса уловил. По всей видимости, Вы о снижении кол-ва кода, которого можно добиться с помощью комбинации DynamicTest и @TestFactory. Обязательно попробую, спасибо.
Безусловно, интеграционными тестами мы также можем закрыть эту задачу.
У меня следующий довод: такой «юнит» дешевле чем интеграционный тест, в добавок ниже всех в иерархии, а значит первым отвалится, если что не так. То есть быстрее укажет на ошибку.
Тут важно добавить контекста- тестировщиков меньше чем разработчиков, поэтому в данном конкретном случае разработка такими тестами заранее снимает часть вопросов, которые могут возникнуть в дальнейшем, т.е. в какой-то степени разгружает тестирование.
Такие тесты (@JsonTest) проверяют корректность настройки Jackson’а, которую мы реализуем в соответствии с контрактом.
Пример:
Мы описываем DTO, настраиваем:
* форматы дат (@JsonFormat);
* имена полей (@JsonProperty);
* алиасы (@JsonAlias) также иногда настраиваем для десериализации;
* DTO может использовать ENUM’ы, которые сериализуются не “as-is”, а, к примеру MALE/FEMALE должны в итоге выглядеть как мужской/женский и т.п (@JsonValue).
Когда мы все это настроили, то проверяем, что результат соответствует требуемому (согласно постановке/договоренностям) контракту. То есть результат сериализации мы сравниваем с эталонным JSON, который рассчитываем получить, а десериализации - с объектом, который из него собирается.
Спасибо за интересный вопрос.
Так как я и есть один из разработчиков - меня даже и убеждать не пришлось :). На самом деле просто слишком высока цена ошибки. Ведь API внешний, им пользуются много потребителей. Они разрабатывают своё ПО для интеграции с нами. Стоит что-то пропустить и затем либо вечно об этом помнить, чтобы никому ничего не сломать, либо долгая процедура - договориться с потребителями. Оба пути неприятные - костыли либо репутационные риски. Поэтому пока тест не написал, считай - не проверил.
Полностью согласен, покрываются соседними тестами, статический анализатор может пропустить. Да, как Вы верно сказали, остается code review.
Здравствуйте.
Задача, которую он решает, хоть и возникла в моей организации, но все же не является специфической конкретно для нее. Поэтому он может быть применен не только там где я работаю. А если он может быть полезен где-то еще, то стоит опубликовать. Я так размышлял.
Вариант не рассматривал, но суть вопроса уловил. По всей видимости, Вы о снижении кол-ва кода, которого можно добиться с помощью комбинации
DynamicTestи@TestFactory. Обязательно попробую, спасибо.