Как я могу выполнить единый тестовый код, использующий интерфейс Fluent?

Question

Я создал несколько небольших плавных интерфейсов с помощью цепочки методов. Обычно они вызывают несколько репозиториев, которые извлекают данные из веб-служб/баз данных.

Как я могу использовать методы модульного тестирования, которые используют свободный интерфейс?

Public IEnumberable<Computer> FindComputers(string serialNumber) 
{ 
     return Computers.FindBySerialNumber("YBCX00900") 
     .AttachConfiguration() 
     .EnsureAllComputersHaveConfiguration(); 
} 

я могу модульное тестирование отдельных компонентов текучего интерфейса, но если я хочу модульное тестирование методы FindComputers выше, что я должен делать?

1. Используйте конкретную реализацию беглого интерфейса, и писать ожидания в хранилище классов
2. Mock сам беглый интерфейса и установить ожидания на этом
3. Test только беглый интерфейс самого, а не FindComputers()

Я хотел бы найти легко ремонтный подход.

Answer 1

Я думаю, что FI делает больше, чем нужно. Я предполагаю, что вы используете «Компьютеры» в качестве преобразователя данных, а также используете его для построения запроса. Из того, что вы показали, запрос строится из этого:

rule 1: find configured computer with serial number = "whatever" and has-config = true. 
rule 2: find not-config computer with serial number = "whatever and has-config = true. 
rule 3: find configured computer with serial number = "whatever" and has-config = false. 
rule 4: find not-config computer with serial number = "whatever" and has-config = false. 
rule 5: find all computer with serial number = "whatever" and has-config = true. 
rule 6: find all computer with serial number = "whatever" and has-config = false. 

и так далее ...

Теперь некоторые из этих правил, которые могут быть реализованы как представляется неверным. правило 2 и правило 3, по-видимому, находятся в разных целях. правило 5 и правило 6 делает что? Это верно?

Потому что вы реализовали объект, который разбивает SRP. Первый шаг - сломать построитель запросов из модуля отображения данных. Создайте свой объект запроса FI, затем передайте его в устройство отображения.

Теперь вы можете проверить FindComputers, убедившись, что объект запроса FI отправляется в устройство отображения данных. Поскольку теперь вы можете создать объект запроса FI, вы можете его протестировать. И вы можете проверить, что dataperper использует объект запроса.

Что делать, если в будущем вы хотите найти компьютеры по местоположению. Если вы сохраните тот же код, что и вы написали, вам нужно будет добавить метод FindByLocation, и, прежде чем вы это узнаете, у вас есть объект-бог. вонючий!

Answer 2

сделаю 2 + 3. Предполагая, что свободные интерфейсы являются истинными интерфейсами, они должны быть относительно просты для фальсификации. Просто осознайте, что каждый шаг в цепочке вызовов должен, вероятно, возвращать новый макет-объект, который, в свою очередь, ожидает следующего вызова в цепочке.

Вы все равно должны протестировать свободный интерфейс, хотя, высмеивая слой репозитория под ними.

Answer 3

Можете вы издеваться над своими репозиториями? Хотя некоторые будут выступать за более чистый подход, когда вы должны изолировать один метод одного класса, было бы достойным способом проверить, как FindComputers и свободный интерфейс работают вместе. И это может быть проще, в зависимости от того, как выглядит слой доступа к репозиторию.