Здравствуйте, ·, Вы писали:

g>> Если в крупной json меняется пара полей, то интегротест же выдаёт diff конкретно для сломанного поля, что позволяет быстро определить точку поломки.
·>Да. Но так как этих json сотни, то тебе тупо выдаст сотни диффов с одним и тем же полем, и нужно пройтись по всем этим json-ам и добавить туда одно и то же. Совершенно бесполезно и даже вредно, типичный копипаст.

В описываемом мною подходе нет сотни диффов, потому что интегротесты не тестируют все краевые условия и классы эквивалентности, иначе прогон интегротестов займет сутки, это слишком "дорого", для этого существуют "дешевые" юнит-тесты, которые гоняются на порядок быстрее и могут пройтись по всем значимым входным и выходным значениям. Интегротесты тестируют в основном критический путь, и то дишь в том объеме, чтобы проверить исполнение контракта для любого из значений, а не для всех классов эквивалентности. Поэтому интегротестов на практике получается не так много.

g>> Поэтому не очень понимаю, в чём проблема использования больших json, цельных с точки зрения реквест-респонзов.
·>В том, что желательно иметь минимальные изменения. Одно поле добавлено — один тест поправлен. (повторюсь, это идеал, но хочется к нему стремиться)

К сожалению, я не видел ни разу, чтобы подобный подход приводил к хорошо поддерживаемым понятным тестам, обычно это приводило к разрастанию точечных тестов, когда за деревьями не видно леса (за нагромождением точечных тестов не видно общей логики работы тестируемой системы), и те, кто приходит потом на суппорт этих тестов, не понимают ни логики их построения, ни могут их далее поддерживать.

Здравствуйте, ·, Вы писали:

g>> Если в крупной json меняется пара полей, то интегротест же выдаёт diff конкретно для сломанного поля, что позволяет быстро определить точку поломки.
·>Да. Но так как этих json сотни, то тебе тупо выдаст сотни диффов с одним и тем же полем, и нужно пройтись по всем этим json-ам и добавить туда одно и то же. Совершенно бесполезно и даже вредно, типичный копипаст.

В описываемом мною подходе нет сотни диффов, потому что интегротесты не тестируют все краевые условия и классы эквивалентности, иначе прогон интегротестов займет сутки, это слишком "дорого", для этого существуют "дешевые" юнит-тесты, которые гоняются на порядок быстрее и могут пройтись по всем значимым входным и выходным значениям. Интегротесты тестируют в основном критический путь, и то дишь в том объеме, чтобы проверить исполнение контракта для любого из значений, а не для всех классов эквивалентности. Поэтому интегротестов на практике получается не так много.

g>> Поэтому не очень понимаю, в чём проблема использования больших json, цельных с точки зрения реквест-респонзов.
·>В том, что желательно иметь минимальные изменения. Одно поле добавлено — один тест поправлен. (повторюсь, это идеал, но хочется к нему стремиться)

К сожалению, я не видел ни разу, чтобы подобный подход приводил к хорошо поддерживаемым понятным тестам, обычно это приводило к разрастанию точечных тестов, когда за деревьями не видно леса (за нагромождением точечных тестов не видно общей логики работы тестируемой системы), и те, кто приходит потом на суппорт этих тестов, не понимают ни логики их построения, ни могут их далее поддерживать. Возможно, если писать точечные тесты правильно, то таких проблем не будет, но обычно никто не умеет их писать правильно, тут ситуация очень похожа на то, как сейчас применяют DDD, тоже мало кто понимает, но начинают применять, и делают это неправильно, что приводит к невозможности другим людям развивать такие "DDD" решения и вообще к неотчуждаемости такого кода.