Поблочное тестирование: вход и внедрение зависимости

Я написал всего несколько модульных тестов для ведения журнала. Это больно, либо запутать производственный код (из-за внедрения регистратора), либо тест вонючий (замена статического регистратора на макет). В отличие от McWafflestix, я часто не обнаруживал, что это того стоит.

Насколько вы действительно хотите знать, работает ли ведение журнала, помимо того, что вы увидите через других (руки -на) тестирование? Возможно, вы захотите использовать DI для случайных классов, где ведение журнала действительно важно, но в противном случае я бы просто не утруждал себя тестированием ведения журнала.

Предполагается, что журнал имеет отладочную природу - если это аудит ] журнал или что-то в этом роде (что-то с функциональными требованиями), это другое дело.

Я бы разделил ведение журнала на три категории:

1) Требование. Некоторые системы требуют ведения журнала для целей аудита или для выполнения некоторых других требований проекта (например, стандарта ведения журнала на сервере приложений). Тогда это действительно требование и заслуживает модульных и приемочных тестов до такой степени, что вы можете быть уверены, что это требование выполнено. В этом случае можно проверить точную строку журнала.

2) Решение проблем. Если вы начинаете получать странное состояние в QA или продакшене, вы хотите иметь возможность отслеживать, что происходит. В общем, я бы сказал, что если это важно (скажем, в многопоточном приложении, где состояние может быть сложным, но не может быть воспроизведено с помощью известных шагов), то проверка того, что данные значения состояния в конечном итоге регистрируются, может быть ценным (так что вы ' t проверка всей читабельности журнала, только то, что в него попадают определенные факты). Даже если класс будет изменен позже, это состояние все равно будет регистрироваться (вместе с дополнительным состоянием), поэтому связь между тестом и регистрацией является разумной. Таким образом, в этом случае проверяется только часть журнала (a contains test).

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

 logger.debug("Extract the fifth instance of BLAH from the string " + s);

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

Что касается представления о том, что вы должны тестировать 100% всего, см. Ответ Кента Бека ] здесь . Я думаю, что "

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

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

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

Например, Java's Log4J позволяет вам объявлять пользовательские приложения , которые являются компонентами, ответственными за «доставку» LoggingEvent.

Регистратор. можно легко смоделировать и внедрить с помощью:

Appender appenderMock = EasyMock.createMock(Appender.class);
/* expect */ appenderMock.doAppend(EasyMock.isA(LoggingEvent.class));
EasyMock.replay(appenderMock);

Logger.getLogger(/* replace with your own */"My logger").addAppender(appenderMock);

EasyMock.verify(appenderMock);

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

Я обычно не использую операторы ведения журнала модульных тестов, утверждая, что они записаны, но я проверяю, что пути кода, используемые моими модульными тестами, охватывают операторы журналирования, просто чтобы убедиться, что я не получаю исключение при регистрации исключения!

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

DoSomething()
{
    if (FatalErrorOccurred)
    {
        Logger.Log("Fatal Error", ErrorLevel.Fatal);
    }
}

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

Хотя я согласен с другими в том, что я не буду применять TDD для ведения журнала, я бы попытался убедиться, что модульное тестирование охватывает все пути кода, содержащие операторы ведения журнала. И, что важно, убедитесь, что во время выполнения модульных тестов настроен самый высокий уровень детализации, чтобы выполнялись все операторы ведения журнала.

Например, в следующем коде есть ошибка, которая вызывает исключение FormatException, только если включена трассировка уровня отладки.

if (logger.IsDebugEnabled)
{
    string message = String.Format(CultureInfo.CurrentCulture, 
          "... {1} ...", someValue);
    logger.Debug(message);
}