Мне нужно взаимодействовать с веб-API. Он принимает почтовые запросы и возвращает данные XML. Это требует много асинхронной обработки на стороне клиента, чтобы он мог повторять несколько раз в случае сбоя, не прерывая основной процесс клиента. Код должен быть хорошо протестирован. Я создаю макет версии API для тестирования на локальном уровне и записи модульных тестов, которые подключаются к нему. Это хороший подход для тестирования? Должен ли я также иметь версии клиентского API, которые подделывают соединение с сервером и на самом деле не соединяются? (просто верните макет данных)
Я также пытаюсь определить лучшую архитектуру для классов запроса/ответа. Должен ли я просто сериализовать ответ в классе? Должен иметь какой-то файл сопоставления, который отображает поля XML в свойства класса? Я думал о наличии класса запроса для каждого запроса, который следует за интерфейсом. Тогда я мог бы иметь класс ApiRequestSender, а также класс AsyncApiRequestSender, который отправляет запрос и получает ответ. Единственное, с чем я смущен, заключается в том, как получить правильно напечатанный ответ, так как есть 4.
Спасибо заранее. Я надеюсь получить ответы, но обычно, когда я задаю вопросы, основанные на архитектуре, я не получаю никаких ответов: <
Определенно хороший способ зайти так далеко.
IService
или IRepository
и абстрагировал ваш код от веб-API и использовал контейнер DI для внедрения вашей макетной реализации для тестирования и реального API для приложения.НТН
Я думаю, что насмехаться над API - это путь. Цель состоит в том, чтобы протестировать клиентскую сторону вашего приложения, а не подключаться API, это не будет иметь добавленной стоимости для ваших тестов.
Не изобретайте колесо: используйте сериализацию вместо написания собственного механизма отображения.