Как проверить метод Void без аргументов, выводящих строку на консоль - PullRequest
Новая
       47

Как проверить метод Void без аргументов, выводящих строку на консоль

0 голосов
/ 21 февраля 2020

Для домашнего задания я создал класс с именем Bird, который содержит метод: 

public void launch()
{
     System.out.println("Flapping the wings until take-off");
}

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

@Test
    void testLaunch()
    {
        Bird myBird = new Bird("Macaw");
        assertEquals("Flapping the wings to take-off", myBird.launch());
    }

мне дают эту ошибку в Eclipse: «Метод assertEquals (short, short) в типе Assertions не применим для аргументов (String, void)»

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

Ответы [ 2 ]

1 голос
/ 21 февраля 2020

Вы можете использовать System.setOut(PrintStream) для временной замены стандартного выхода входящей памятью PrintStream, поддерживаемой ByteArrayOutputStream, и использовать его для получения выходных данных. Что-то вроде 

@Test
void testLaunch() {
    PrintStream original = System.out;
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    PrintStream tps = new PrintStream(baos);
    Bird myBird = new Bird("Macaw");
    System.setOut(tps);
    myBird.launch();
    System.setOut(original);
    tps.flush();
    assertEquals("Flapping the wings to take-off", baos.toString());
}
0 голосов
/ 21 февраля 2020

Обычно вы тестируете только те методы, в которых есть какая-то логика c. Вызов System.out.println не считается логическим c.

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

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

Глядя на эту структуру теста указывает на тот факт, что базовый метод не только опирается на побочные эффекты, но это также делать три вещи одновременно (тогда как идеальные методы делают только одно). он создает Object (здесь String), получает и OutStream (здесь System.out) и использует оба вместе (println).

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

...