Как проверить обратные вызовы с NUnit

Question

Есть ли какая-то особая поддержка, когда вы приходите тестировать обратные вызовы с NUnit? Или какая-то «лучшая практика», которая лучше моего решения ниже?

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

В тестируемом методе используется делегат, который вызывает функцию обратного вызова, например, как только в потоке обнаруживается новый элемент xml. Для целей тестирования я передаю делегату метод NewElementCallback и сохраняю содержимое аргументов в некоторых свойствах тестовых классов при вызове функции. Эти свойства я использую для утверждения. (Конечно, они сбрасываются в настройках теста)

[Test]
public void NewElement()
{
    String xmlString = @"<elem></elem>";

    this.xml.InputStream = new StringReader(xmlString);
    this.xml.NewElement += this.NewElementCallback;

    this.xml.Start();

    Assert.AreEqual("elem", this.elementName);
    Assert.AreEqual(0, this.elementDepth);
}

private void NewElementCallback(string elementName, int elementDepth)
{
    this.elementName = elementName;
    this.elementDepth = elementDepth;
}

Answer 1

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

[Test]
public void NewElement()
{
    String xmlString = @"<elem></elem>";
    string elementName;
    int elementDepth;

    this.xml.InputStream = new StringReader(xmlString);
    this.xml.NewElement += (name,depth) => { elementName = name; elementDepth = depth };

    this.xml.Start();

    Assert.AreEqual("elem", elementName);
    Assert.AreEqual(0, elementDepth);
}

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

Answer 2

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

Answer 3

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