Убедитесь, что временные объекты созданы - PullRequest
Новая
       2

Убедитесь, что временные объекты созданы

0 голосов
/ 05 октября 2018

Я нахожусь в контексте Java и использую Mockito (но я не привязан к нему) для базовых нужд насмешек.

У меня есть такой код 

public class AuditInfoSerializer {

    [..]

    public Map<String, Object> doStuff(Object a) {
        doOtherStuff("hello", new TempClass(someField, <someParams>));
        doOtherStuff("world", new TempClass(someField, <otherParams>));
        return getResult();
    }
}

ив тесте я хочу убедиться, что есть два экземпляра TempClass, созданные с правильным набором параметров, когда я вызываю метод doStuff.

Возможно ли это как-то?

Ответы [ 2 ]

0 голосов
/ 05 октября 2018

По большей части я согласен с точкой зрения @ davidxxx о фиктивной проверке компромисса.Если у вас есть настройка, которая позволяет вам делать утверждения о результате, таком как карта, которая создается в результате, сделайте это!

С точки зрения API doStuff - это простой прямой метод: броситьчто-то на это, получить что-то обратно.Информация, которая вас интересует, будет содержаться на карте (это будет ваше утверждение).

Многое происходит под капотом , прежде чем doStuff что-то вернет.Многие люди стремятся разрушить инкапсуляцию при тестировании.Они постоянно ищут способы раскрыть, что происходит за кулисами.Я считаю, что это совершенно естественно.Но, конечно, это также анти паттерн.Неважно, какой инструмент вы используете (неправильно), чтобы нарушать естественные границы (насмешливые фреймворки, пользовательские отражения, «черные двери» в вашей базе кода и т. Д.)Это всегда неправильно.Как уже отмечал @Michael, вызов doOtherStuff действительно является деталью реализации.Возьмите перспективу клиентского кода, который делает вызов doStuff.Интересно , как создается карта?Я сомневаюсь.Это также должно быть вашей перспективой тестирования.

И последнее, что нужно сделать при использовании проверки в тестах.Я хотел бы смягчить компромиссное заявление.Мне действительно не нравится обобщение здесь.Проверка не всегда является всегда менее привлекательным выбором по сравнению с реальными утверждениями: 

// Valid test without any verifaction
@Test
void method_foo_returns_gibberish (@Mock SomeInput someInput) {

    // Maybe this is just to prevent an NPE ...
    when(someInput.readStuff()).thenReturn("bla");

    assertEquals("gibberish", Foo.foo(someInput));

}


// Test made possible by verification
@Test
void method_foo_is_readonly (@Mock SomeInput someInput) {

    Foo.foo(someInput);
    verify(someInput.readStuff());
    verifyNoMoreInteractions(mockedList);

}

Это только самый очевидный пример, который я мог придумать.Есть часть гениев BDD, которые стремятся построить всю свою архитектуру на основе проверочных тестов! Вот отличная статья Мартина Фаулера

Когда речь идет о тестировании, в большинстве случаев нет черного и белого.Использование насмешек и проверки означает написание различных тестов.

Как всегда, речь идет о выборе правильного инструмента.

0 голосов
/ 05 октября 2018

Вы не хотите проверять временные данные на тестируемом объекте.Вы хотите смоделировать зависимости и утвердить объект тестируемого поведения: то есть с этим входом у вас есть этот вывод.
Проверка на ложность - это компромисс между методами, которые имитируют, которые ничего не возвращают, а только вызывают побочный эффект.
Так что используйтеэто только потому, что у вас нет выбора.
В вашем модульном тесте вы хотите установить, какой метод для тестирования возвращает getResult().
Сделайте это с Assert.assertEquals(...), а не с Mockito.verify(...).

...