Какой смысл издеваться над этим Feign объектом?

Question

Я пытаюсь написать модульный тест для реализации клиента Feign. Я не был уверен, как это сделать, поэтому я гуглил и наткнулся на этот ответ, и принятым ответом является фрагмент кода:

@Test
public someTestClient(){
    Person expectedPerson = new Person("name",12));
    when(mockPersonClient.getPerson()).return(expectedPerson);
    Person person = mockPersionClient.getPerson();
    assertEquals(expectedPerson, person);
}

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

Person person = new Person("a", 1)
Person expectedPerson = new Person("a", 1)
assertEquals(person, expectedPerson)

Я понимаю, что модульное тестирование должно проверять функциональность изолированно. Будет ли этот тест просто гарантировать, что mockPersonClient существует во время выполнения?

Answer 1

Такой тест не имеет никакого значения.

Вот человек , я собираюсь попросить этот звонок вернуть человек , а затем я проверю, получил ли я человек при вызове этоговещь.Конечно, вы получите человек , вы просто жестко запрограммировали это, так как это полезно?

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

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

Когда выслишком много издеваться, это значит, что тест, который вы пишете, слишком привязан к коду, который он тестирует, он слишком много о нем знает.Модульные тесты не должны этого делать, потому что каждый раз, когда вы изменяете код каким-то небольшим образом, вы обнаруживаете, что теперь вам нужно изменить тест, потому что вы больше не используете 35 интерфейсов, теперь у вас есть 47 для имитации оченьконкретный заказ.Это может не быть проблемой, когда у вас есть один тест, но представьте себе, что происходит, когда у вас есть 1000 тестов ...

Если бы люди пытались кодировать более функциональным способом, этого бы не произошло.Если вы передаете данные, а не абстракции, теперь вам не нужно ничего высмеивать.

Вместо того, чтобы издеваться над вызовом базы данных, изолировать его, взять результат и передать его методу, вы только что потеряли абстракцию, и вашему коду не нужно ничего подделывать, вы просто вызываете метод,передать данные в любом формате, который вы хотите, и посмотреть, что произойдет.

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

Answer 2

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

В этом примере настроенный OP mockPersonClient.getPerson() возвращает фальшивку Person. Однако ему просто интересно, почему фальшивый человек не был возвращен, как настроено, когда он вызвал mockPersonClient.getPerson().Я думаю, что пример кода, который он показал, был только для того, чтобы продемонстрировать этот вопрос.Это не значит, что он на самом деле написал эти коды модульного тестирования для проверки некоторых производственных кодов.