Недействительные методы модульного тестирования?

это будет иметь какое-то влияние на объект .... запросить результат эффекта. Если это не дает видимого эффекта, то модульное тестирование не стоит!

Зависит от того, что он делает. Если у него есть параметры, передайте имитации, которые вы могли бы позже спросить, были ли они вызваны с правильным набором параметров.

Как всегда: проверьте, что должен делать этот метод!

Должен ли он где-то изменить глобальное состояние (э-э, запах кода!)?

Должен ли он вызывать интерфейс?

Должен ли он вызывать исключение при вызове с неправильными параметрами?

Должен ли он не вызывать исключения при вызове с правильными параметрами?

Должен ли он ...?

Предположительно, метод что-то делает, а не просто возвращает?

Если это так, тогда:

1. Если он изменяет состояние своего объекта-владельца, вы должны проверить правильность изменения состояния.
2. Если он принимает какой-либо объект в качестве параметра и изменяет этот объект, вы должны проверить, правильно ли изменен объект.
3. Если в некоторых случаях возникают исключения, проверьте, правильно ли выбрасываются эти исключения.
4. Если его поведение меняется в зависимости от состояния его собственного объекта или какого-либо другого объекта, предварительно установите состояние и проверьте, что метод имеет правильный I (с помощью одного из трех методов тестирования, описанных выше).

Если вы сообщите нам, что делает этот метод, я мог бы быть более конкретным.

Если метод ничего не возвращает, это одно из следующих

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

Императивные методы - вы можете проверить, действительно ли задача была выполнена. Проверьте, действительно ли произошло изменение состояния. например

void DeductFromBalance( dAmount ) 

можно проверить, проверив, действительно ли сообщение о балансе меньше начального значения на dAmount

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

void OnAccountDebit( dAmount )  // emails account holder with info

можно проверить, проверив, отправляется ли электронное письмо

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

string[] ExamineLogFileForX( string sFileName );
void InsertStringsIntoDatabase( string[] );

String [] можно легко проверить, предоставив первому методу фиктивный файл и ожидаемые строки. Второй вариант немного сложен ... вы можете либо использовать Mock (google или search stackoverflow на имитирующих фреймворках), чтобы имитировать БД, либо нажать на фактическую БД и проверить, были ли строки вставлены в правильное место. Поищите в эта ветка хорошие книги ... Я бы порекомендовал Pragmatic Unit Testing, если вы испытываете затруднения. В коде это будет использоваться как

InsertStringsIntoDatabase( ExamineLogFileForX( "c:\OMG.log" ) );

Проверьте его побочные эффекты. Это включает:

• Есть ли исключения? (Если должно, проверьте, что это так. Если нет, попробуйте несколько угловых случаев, которые могут быть, если вы не будете осторожны - нулевые аргументы являются наиболее очевидным.)
• Хорошо ли играет со своими параметрами? (Если они изменчивы, мутирует ли он их, когда не должен, и наоборот?)
• Правильно ли он влияет на состояние объекта / типа, для которого вы его вызываете?

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

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

Типы возврата / подпрограммы - старые новости. Я не создавал возвращаемый тип Void (если только я не был очень ленив) примерно за 8 лет (со времени этого ответа, так что незадолго до того, как был задан этот вопрос).

Вместо такого метода, как:

public void SendEmailToCustomer()

Создайте метод, соответствующий парадигме Microsoft int.TryParse ():

public bool TrySendEmailToCustomer()

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

Кроме того, bool - не единственный тип состояния. Есть несколько случаев, когда ранее созданная подпрограмма могла фактически возвращать три или более разных состояния (хорошее, нормальное, плохое и т. д.). В таких случаях вы просто использовали бы

public StateEnum TrySendEmailToCustomer()

Однако, хотя Try-Paradigm отчасти отвечает на этот вопрос о том, как проверить возврат недействительности, есть и другие соображения. Например, во время / после цикла «TDD» вы выполняете «рефакторинг» и замечаете, что делаете две вещи с вашим методом ... тем самым нарушая «принцип единой ответственности». Так что об этом нужно позаботиться в первую очередь. Во-вторых, вы могли определить зависимость ... вы касаетесь «постоянных» данных.

Если вы выполняете доступ к данным в рассматриваемом методе, вам необходимо выполнить рефакторинг в n-уровневую или n-уровневую архитектуру. Но мы можем предположить, что когда вы говорите «Строки затем вставляются в базу данных», вы на самом деле имеете в виду, что вызываете уровень бизнес-логики или что-то в этом роде. Да, предположим.

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

public <Constructor/MethodName> (IBusinessDataEtc otherLayerOrTierObject, string[] stuffToInsert)

Теперь, когда вы можете принять интерфейс вашего объекта уровня бизнеса / данных, вы можете смоделировать его во время модульных тестов и не иметь никаких зависимостей или опасений «случайного» интеграционного тестирования.

Итак, в вашем живом коде вы передаете НАСТОЯЩИЙ объект IBusinessDataEtc. Но в модульном тестировании вы передаете объект MOCK IBusinessDataEtc. В этот макет вы можете включить свойства, не относящиеся к интерфейсу, такие как int XMethodWasCalledCount или что-то, чье состояние (я) обновляется при вызове методов интерфейса.

Таким образом, ваш модульный тест будет проходить через ваш Method (s) -In-Question, выполнять любую имеющуюся у них логику и вызывать один или два или выбранный набор методов в вашем объекте IBusinessDataEtc. Когда вы делаете свои утверждения в конце модульного теста, у вас есть пара вещей, которые нужно проверить сейчас.

1. Состояние «подпрограммы», которое теперь является методом Try-Paradigm.
2. Состояние вашего объекта Mock IBusinessDataEtc.

Для получения дополнительной информации об идеях внедрения зависимостей на уровне построения ... поскольку они относятся к модульному тестированию ... загляните в шаблоны проектирования Builder. Он добавляет еще один интерфейс и класс для каждого текущего интерфейса / класса, который у вас есть, но они очень крошечные и обеспечивают ОГРОМНОЕ увеличение функциональности для лучшего модульного тестирования.

Попробуй это:

[TestMethod]
public void TestSomething()
{
    try
    {
        YourMethodCall();
        Assert.IsTrue(true);
    }
    catch {
        Assert.IsTrue(false);
    }
}

Какой бы экземпляр вы ни использовали для вызова метода void, вы можете просто использовать Verfiy

Например:

В моем случае его _Log - это экземпляр, а LogMessage - метод, который нужно протестировать:

try
{
    this._log.Verify(x => x.LogMessage(Logger.WillisLogLevel.Info, Logger.WillisLogger.Usage, "Created the Student with name as"), "Failure");
}
Catch 
{
    Assert.IsFalse(ex is Moq.MockException);
}

Выдает ли Verify исключение из-за сбоя метода, который тест не прошел?

Вы даже можете попробовать это так:

[TestMethod]
public void ReadFiles()
{
    try
    {
        Read();
        return; // indicates success
    }
    catch (Exception ex)
    {
        Assert.Fail(ex.Message);
    }
}