Помогите в разработке тестируемого API-клиента

2

Мне нужно взаимодействовать с веб-API. Он принимает почтовые запросы и возвращает данные XML. Это требует много асинхронной обработки на стороне клиента, чтобы он мог повторять несколько раз в случае сбоя, не прерывая основной процесс клиента. Код должен быть хорошо протестирован. Я создаю макет версии API для тестирования на локальном уровне и записи модульных тестов, которые подключаются к нему. Это хороший подход для тестирования? Должен ли я также иметь версии клиентского API, которые подделывают соединение с сервером и на самом деле не соединяются? (просто верните макет данных)

Я также пытаюсь определить лучшую архитектуру для классов запроса/ответа. Должен ли я просто сериализовать ответ в классе? Должен иметь какой-то файл сопоставления, который отображает поля XML в свойства класса? Я думал о наличии класса запроса для каждого запроса, который следует за интерфейсом. Тогда я мог бы иметь класс ApiRequestSender, а также класс AsyncApiRequestSender, который отправляет запрос и получает ответ. Единственное, с чем я смущен, заключается в том, как получить правильно напечатанный ответ, так как есть 4.

Спасибо заранее. Я надеюсь получить ответы, но обычно, когда я задаю вопросы, основанные на архитектуре, я не получаю никаких ответов: <

Теги:

2 ответа

1

Определенно хороший способ зайти так далеко.

  • Mocking поможет вам получить много дел, не нажимая на службу.
  • Если возможно, проверьте, можете ли вы вставлять ввод/вывод API в свой собственный класс для своего кода, чтобы вы могли кодировать свои классы и не беспокоиться о состояниях ответа, которые будут обернуты.
  • Как правило, я бы превратил его в реализацию IService или IRepository и абстрагировал ваш код от веб-API и использовал контейнер DI для внедрения вашей макетной реализации для тестирования и реального API для приложения.
  • Как сказал @Gerrie, не заново изобретайте колесо, если оно не квадратное:)

НТН

1

Я думаю, что насмехаться над API - это путь. Цель состоит в том, чтобы протестировать клиентскую сторону вашего приложения, а не подключаться API, это не будет иметь добавленной стоимости для ваших тестов.

Не изобретайте колесо: используйте сериализацию вместо написания собственного механизма отображения.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню