Всем привет!
Возникло разногласие с коллегами по поводу тестовой стратегии и оптимального покрытия тестами функционала приложения. Заказчик ждет предложение от нас.
Приложение трансформирует JSON объекты из одного формата (#1) в другой (#2). Для каждого поля есть подробная документация с правилами трансформации. Типов JSON объектов (поле "type") - более десятка, для каждого типа есть обязательные и опциональные поля.
К примеру, JSON из формата #1
{
"type": "Person",
"firstName": "Ivan",
"lastName": "Ivanov",
"age": 20,
"description": "Ivan Ivanov is ...",
"hobbies": null,
"education": [{"BSU"}, {"BSUIR"}]
}
будет трансформирован в
{
"type": "Person",
"name": "Ivan Ivanov",
"personAge": 20,
"description": "Description: Ivan Ivanov is ...",
"education": {"BSU, BSUIR"}
}
Поля, выделенные жирным - обязательные для формата #1.
Т. е., у некоторых полей может поменяться название ключа, значение, некоторые поля с пустыми значениями/null игнорируются, массив может преобразовываться в объект и наоборот.
Вопрос: как оптимально протестировать такие трансформации?
В планах это делать с помощью автоматизации.
Мое мнение: использовать JSON схемы для тестирования и структуры и значений полей. Для каждого типа объекта создать базовую схему, которая включает обязательные поля. Для каждого опционального поля создавать отдельную схему, которая наследуется от базовой и включает это поле. Таким образом, проверяется, что после трансформации получаем правильную структуру JSON объекта. Для тестирования значений полей можно использовать эти же схемы, в которых указывать какое значение ожидаем.
В итоге имеем следующие отдельные тесты на структуру и на значения полей:
- Позитивные тесты только с обязательными полями. Граничные значения, классы эквивалентности, спецсимволы и т. д.;
- Негативные тесты только с обязательными полями. К примеру, отсутствующее обязательное поле, недопустимые значения;
- Позитивные тесты на обязетельные поля + одно опциональное поле. Здесь тестируется только опциональное поле. Граничные значения, классы эквивалентности, спецсимволы и т. д.;
- Негативные тесты на опциональное поле. Недопустимые значения.
Плюсы: атомарные тесты. Если сломалась трансформация только для одного опционального поля, упадут только тесты, связанные с этим полем. Легко и быстро добавлять новые тесты. Если добавилось одно обязательно поле, достаточно добавить его в базовую схему и создать несколько отдельных тестовых методов для него. Проверяется структура объектов. Большое покрытие проверок значений полей (и позитивные и негативные).
Минусы: большое количество схем, которое необходимо хранить в проекте и большое количество тестов - на каждое поле несколько позитивных и негативных тестов.
Мнение коллег: достаточно создать несколько JSON объектов для каждого типа с максимальным количеством полей каждый, где комбинировать разные значения для значений этих полей. Тестировать только позитивные кейсы. Структуру не тестировать вообще.
Плюсы: небольшое количество тестовых методов и данных.
Минусы: если ломается трансформация одного поля, упадут все тесты, где используется тестовый JSON объект с этим полем. Из-за этого не узнаем, работает ли трансформация для других полей. Если не тестировать структуру, вполне возможно, что из-за бага могут появится лишние поля.
Какой подход вы бы выбрали? Если никакой из предложенных, поделитесь идеями, как бы вы организовали тестирование таких трансформаций?
