Модульное тестирование пустых методов?
Согласно man-странице в Linux, abort () генерирует SIGABRT для процесса, который может быть захвачен обработчиком сигнала. EDIT: Бен подтвердил, что это возможно и для Windows - см. Его комментарий ниже.
7 ответов
Если метод ничего не возвращает, это - любой один из следующих
- императив - Вы или спрашиваете объект сделать что-то к себе.. например, состояние изменения (не ожидая подтверждения.. его принятый, что это будет сделано)
- информационный - просто уведомление кого-то, что что-то произошло (не ожидая действие или ответ) соответственно.
Обязательные методы - можно проверить, была ли задача на самом деле выполнена. Проверьте, произошло ли изменение состояния на самом деле. например,
void DeductFromBalance( dAmount )
может быть протестирован путем проверки, добавляет ли баланс это сообщение, действительно меньше, чем начальное значение dAmount
, Информационные методы - редки как интерфейс представителя общественности объекта... следовательно не обычно протестированного на единицу. Однако, если Вы должны, можно проверить, происходит ли обработка, которая будет сделана на уведомлении. например,
void OnAccountDebit( dAmount ) // emails account holder with info
может быть протестирован путем проверки, посылается ли электронное письмо
Сообщение, больше деталей о фактическом методе и людях будет в состоянии ответить лучше.
Обновление : Ваш метод делает 2 вещи. Я на самом деле разделил его на два метода, которые могут теперь быть независимо протестированы.
string[] ExamineLogFileForX( string sFileName );
void InsertStringsIntoDatabase( string[] );
Строка [] может быть легко проверена путем предоставления первому методу с фиктивным файлом и ожидала строки. Второй немного хитер.. можно или использовать Насмешку (Google или искать stackoverflow при насмешке платформ) подражать DB или поражать фактический DB и проверить, были ли строки вставлены в правильное местоположение. Проверьте этот поток для некоторых хороших книг... Я повторно прокомментировал бы Прагматическое Поблочное тестирование, если Вы находитесь в уплотнении.
В коде это использовалось бы как [1 116]
InsertStringsIntoDatabase( ExamineLogFileForX( "c:\OMG.log" ) );
Как всегда: протестируйте то, что метод, как предполагается, делает!
Должен он изменять глобальное состояние (uuh, кодировать запах!) где-нибудь?
это должно звонить в интерфейс?
это должно выдать исключение, когда названо с неправильными параметрами?
это не должно выдавать исключение, когда названо с правильными параметрами?
Должен он...?
Протестируйте его побочные эффекты. Это включает:
- это выдает какие-либо исключения? (Если это должно, проверить, что это делает. Если это не было должно, рассмотреть некоторые угловые дела, которые могли бы, если Вы не осторожны - нулевые аргументы, являющиеся самой очевидной вещью.)
- это играет приятно со своими параметрами? (Если они изменяемы, это видоизменяет их, когда это не было должно и наоборот?)
- это имеет правильный эффект на состояние объекта/типа, Вы обращаетесь к нему?
, Конечно, существует предел тому, как очень можно протестировать. Вы обычно не можете тестировать с каждым возможным входом, например. Протестируйте практично - достаточно, чтобы вселить Вам веру, что Ваш код разработан соответственно и реализован правильно, и достаточно действовать как дополнительная документация для того, что могла бы ожидать вызывающая сторона.
это будет иметь некоторый эффект на объект.... запрашивают для результата эффекта. Если это не имеет никакого видимого эффекта не стоящий поблочного тестирования!
Используйте Насмешки Носорога для установки, какие вызовы, действия и исключения могли бы ожидаться. Принятие Вас может дразнить или погасить части Вашего метода. Трудно знать, не зная некоторых специфических особенностей здесь о методе, или даже контексте.
По-видимому, метод делает что-то и просто не возвращается?
Принятие дело обстоит так, тогда:
- , Если это изменяет состояние, он - объект владельца, тогда необходимо протестировать это состояние, измененное правильно.
- , Если это берет в некотором объекте в качестве параметра и изменяет тот объект, тогда Ваш, должен протестировать объект, правильно изменяется.
- , Если это выдает исключения, определенные случаи, протестируйте это, те исключения правильно выдаются.
- , Если его поведение варьируется на основе состояния его собственного объекта или некоторого другого объекта, задает состояние и тестируют метод, имеет корректный Ithrough один из этих трех методов тестирования выше).
, Если youy сообщают нам то, что делает метод, я мог быть более конкретным.
Зависит от того, что это делает. Если это имеет параметры, передачу в насмешках, которые Вы могли спросить позже, назвали ли их с правильным набором параметров.