Должен ли бизнес / ядро ​​иметь дело с вызовом API третьей стороны?

Question

У нас есть бизнес-поток, подобный этому

1. Получить данные списка из базы данных
2. Для каждого элемента в списке
3. Преобразовать элемент в JSON
4. Отправка данных третьему лицу для получения результата
5. Сохранение результата в db

Send data будет отличаться в зависимости от третьего лица, один требует использования HTTP, один требует используя FTP или gRP C вызов. Я использую интерфейс, чтобы абстрагировать отправку данных третьей стороне, и пусть API, внешний уровень, решает, какой метод он хочет использовать.

Архитектура соответствует принципу Clean Architect. У нас есть Entity, Business / Core в середине и оболочка по API и инфраструктуре.

Пример кода

In Business/Core project

// Abstract class    
var items = await GetItemsAsync(args); // abstract method
foreach (var item in items)
{
    var json = await ConvertItemToJsonAsync(item); // abstract method
    var resultInString = await SendAsync(json); // abstract method
    await SaveResultAsync(item, resultInString); // abstract method
}

// Now for child classes, they will implement those abstract methods. 
// In this case, it will be

override Task<string> SendAsync(string json)
{
    return _thirdparty.SendDataAsync(json);
}

interface IThirdParty 
{ 
    Task<string> SendDataAsync(string json); 
}

It означает, что дочерние классы будут принимать интерфейс с именем _thirdparty, чтобы отделить данные для отправки третьему лицу. На уровне API будет легко создавать некоторые виды третьих сторон, такие как отправка по HTTP, FPT или gRP C и зарегистрировать DI или лучше фабрику для использования.

Моя забота о модульном тесте, когда вы написать модульный тест, вам нужен контекст, с контекстом, вы знаете, что такое блок для написания тестового примера / скрипта. Например, если мы создаем автомобиль, контекст - это автомобиль, которым можно управлять в принципе. Должны ли мы заботиться о том, какой тип винта колеса используется? Это от поставщиков частей по уходу за сборкой. Если мы проверяем каждую часть сборки, нам нужно заботиться о винте. Это контекст. Если, следуя вышеприведенному пути, я могу легко написать юнит-тест для каждого абстрактного метода и для всего потока, я могу создать фиктивный интерфейс для третьей стороны.

Но есть проблема для Business / Core, поскольку основной целью этого бизнеса является вызов третьей стороны, то есть контекста, остальные методы имеют дело с базой данных, которую нам не нужно проверять.

Чтобы я мог проверить поток в Business / Core, мне нужно перевести конкретный класс сторонних разработчиков из API в Business / Core, а затем проверить его как единое целое. Для этого Business / Core теперь нужно использовать классы HttpClient, gRP C для работы с третьими лицами.

Мой вопрос: должен ли бизнес заботиться о сети, если это ее бизнес? Или у нас есть лучший способ решить это?

Answer 1

Вопрос и (мой) ответ самоуверенны.

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

С учетом сказанного; Я не думаю, что вам следует применять модульное тестирование на «может ездить автомобиль» (это более вероятные интеграционные и регрессионные тесты), вам следует применять модульное тестирование на уровне «винты и болты».

I Я думаю, что вам следует выполнить модульное тестирование вашей основной логики c, даже если она только вызывает сторонние API. Бьюсь об заклад, порядок вещей и обработка ошибок будут важны в этом коде.

Но, как я уже сказал, это всего лишь мои мнения.

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