При тестировании API - Должен ли я проверить валидацию методов API?

Question

Я унаследовал проект, который будет подключаться к системе CRM через службу SOAP, написанный другим разработчиком. У меня вопрос: до какого уровня я должен тестировать интерфейс со службами Soap?

Я настроил тестовый пример и написал несколько методов для проверки метода обновления Soap, и подтвердил, что он потерпел неудачу с подходящим кодом ошибки для недопустимых клиентов или номеров заказов.

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

Я считаю, что должен сообщить об этом разработчику, но должен ли я сейчас удалить этот тест из моего набора тестов? Или оставить это как сбой?

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

Должен ли я вообще разговаривать со службой SOAP через модульные тесты?

Answer 1

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

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

Answer 2

Вы должны написать хотя бы один тест на атомарные функциональные требования. Теперь, если вы пишете с использованием минимальных рекомендаций по интерфейсу, то у вас должно быть не более одного интерфейса на элементарные функциональные требования. Но вы можете написать более одного теста для каждого требования, так как может быть множество инвариантов, которые можно протестировать.

В целом, при написании тестов вы должны учитывать инварианты и функциональные требования, а не методы интерфейса. Тесты> = Атомные функциональные требования.

Answer 3

Если у библиотеки (или стороннего кода) хорошая репутация (например, Apache Commons, Guava ...), я не проверяю API.

Однако, когда я не уверенкачества кода, я склонен написать пару тестов, проверяющих мои предположения о библиотеке / API (но я не проверяю всю библиотеку).

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

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