вход в TDD с помощью Junit

1

Недавно кто-то сказал мне, что мы не должны регистрироваться в тестах JUnit или TDD вообще. Поскольку я начал свою работу с TDD, и это мне очень помогло, я вижу TDD как часть кода, и я использовал log4j для своих методов тестирования. Моя причина: я писал код в тестовых случаях TDD в JUnit, поэтому я должен использовать для этого журнал.

Каково общее распространенное мнение по этому вопросу, я искал это, но не смог найти ничего связанного с этим в google. мой примерный тестовый метод будет выглядеть примерно так, где destinationFileName - это переменная экземпляра класса, которая инициализируется методом @BeforeTest... Скажите, хорошо ли это журналирование или не следует добавлять к методам тестирования.

  @Test
    public void testProcessDestinationByStAX() throws Exception {
        logger.info("Testing processDestinationByStAX");
        DestinationProcessor destinationProcessor = new DestinationProcessor();
        int expResult = numOfDestinations;
        logger.info("parsing  " + destinationFileName);
        List<Destination> result = destinationProcessor.processDestinationByStAX(destinationFileName);
        logger.info("Successfully Parsed  : " + result.size() + " destinations ...");
        assertEquals(expResult, result.size());
    }
Теги:
logging
junit

2 ответа

2
Лучший ответ

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

Я также считаю, что тесты должны быть максимально простыми. Это потому, что людям это не нравится. Чем больше строк кода (включая протоколирование) в ваших тестах, тем сложнее они становятся. Люди будут тратить время, пытаясь понять, что вы делаете. Они не будут тратить время, пытаясь понять, что вы тестируете. По этой причине KISS является ключом к испытаниям.

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

Другой вопрос может быть, если вы проверите протоколирование? Если ваш модуль проверяет, что ожидается ведение журнала. Я не видел много дискуссий об этом, но IMHO, регистрация на уровнях WARNING или выше должна быть проверена.

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

 @Test
public void testProcessDestinationByStAX() throws Exception {
    // setup
    logger.info("Testing processDestinationByStAX");
    DestinationProcessor destinationProcessor = new DestinationProcessor();
    int expResult = numOfDestinations;
    logger.info("parsing  " + destinationFileName);

    // test
    List<Destination> result = destinationProcessor.processDestinationByStAX(destinationFileName);

    // verify
    logger.info("Successfully Parsed  : " + result.size() + " destinations ...");
    assertEquals(expResult, result.size());
}

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

  • 0
    Мне нравится часть форматирования, да, она дает много видимости кода
0

Я думаю, что вырубка полезна в большинстве случаев. Например, время проверки и исключение исключений. Журнал может помочь вам найти проблему. Когда мы запускаем тестовый пример, вы можете увидеть журнал, чтобы узнать, в каком процессе он находится, и также мы можем проверить что-то, что трудно проверить с помощью assert.

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


На мой взгляд, большинству тестовых примеров не требуется log4j для ведения журнала. System.out.println() для большинства сценариев. Сообщение о достоверности гораздо важнее.

Но есть некоторые особые случаи, которые log4j были бы очень полезными. Например, где я могу настроить log4j в тестовом классе JUnit?

Мне по-прежнему нужно запускать тестовый пример сам по себе несколько раз, и в этом случае я хочу настроить log4j.

В этом случае ему нужно, чтобы он выполнялся сам по себе и должен был вести журнал для него.

Конечно, если у вас есть команда для ведения каждого журнала сборки, вы также можете использовать System.out.println. Поскольку teamcity или другие автоматические инструменты помогают вам вести журнал. Если вы не используете эти инструменты и по-прежнему хотите запустить тестовый сценарий много раз, также необходимо знать, когда не удалось выполнить тестовый пример, в котором выполняется сборка, с которой выполняется регистрация. Тогда log4j был бы полезен.

Одним словом, я думаю, нам следует избегать использования log4j в общем тестовом примере Junit, если у нас нет специального требования.

Я думаю, что это не связано с TDD, или в TDD, это не самые важные вещи.

  • 0
    Похоже, вы обсуждаете, является ли log4j правильным механизмом ведения журнала, тогда как возникает вопрос: должно ли вообще происходить ведение журнала.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню