Должен ли я разумно предполагать, что служба будет корректно обрабатывать любые входные данные, возвращая соответствующий код ошибки и сообщение в теле ответа?
это зависит от того, какую платформу вы используетеи что они пишут в руководстве.это также зависит от того, правильно ли вы настроили и правильно ли указаны все правила проверки
Мой вопрос: насколько обширным должно быть отрицательное тестирование?
оно должно быть настолько обширнымкак вы и ваша команда чувствует себя достойным.Цель тестов - дать вам спать лучше.если микросервис является бесплатным сервисом, который возвращает время в указанном часовом поясе, построенном как домашний проект для изучения новых технологий - вероятно, ничего не произойдет, если пользователь передаст неверные данные и произойдет сбой сервиса.если бы это была система управления полетом, я бы проверил, не передадут ли неправильные параметры сотни людей
Так что на самом деле вы и ваша команда - единственные, кто может ответить на этот вопрос
Обычно в реальных системах вы используете один фреймворк, который предоставляет остальные конечные точки.Это работа, чтобы проверить одну из таких конечных точек, чтобы проверить все неправильно сформированные входные данные (неправильный json, неправильный метод и т. Д.), Просто чтобы проверить, правильно ли проверена валидация платформы, а затем вы тестируете каждую отдельную конечную точку, чтобы проверить валидацию, специфичную для этой конечной точки.Параметризованные тесты и сборщики запросов обычно позволяют добавлять такие тесты как однострочные
Дополнительный вопрос - существуют ли определенные символы, которые служба никогда не должна принимать, например, \? <> По соображениям безопасности?
зависит.как вы будете использовать эти данные?если это пароль пользователя, вы обязательно должны его принять - это действительный пароль, верно?но если это номер телефона, который вы собираетесь отображать в виде чистого HTML, вам следует использовать белый список