Тестирование обработки последнего шанса - PullRequest
Новая
       4

Тестирование обработки последнего шанса

0 голосов
/ 10 марта 2009

Я пытаюсь написать модульный тест, чтобы охватить код, найденный в нашем «обработчике исключений последнего шанса».

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

Application.ThreadException AppDomain.CurrentDomain.UnhandledException

Более или менее я проверяю, что создаются журналы, детализирующие информацию, полученную в результате исключения. Мой тест похож на: 

 [Test]
 public void TestMethod() 
 {
    //Setup log4net ConsoleAppender here
    //hooking a MemoryStream to the Console.SetOut done here

    ExceptionHandler.InstallExceptionHandler();
    Thread exceptionThread = new Thread(ThrowException);
    Thread.Start();

    //read stream here

    Assert.That(streamContainsExceptionText);
 }

private void ThrowException() {
 throw new Exception("Unhandled Exception");
}

Обработчик исключений - это синглтон, который, когда «Установлен», просто добавляет обработчики к ранее заданным событиям. Странно то, что у меня нет постоянных результатов. Сбой и отладка, кажется, не вариант, потому что кажется, что он находится между исключением и ExceptionHandler.

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

Кто-нибудь имел опыт тестирования такого кода? Или вы понимаете, почему я вижу такое поведение?

Я использую NUnit 2.4 и запускаю его в IDE с помощью ReSharper.

Ответы [ 2 ]

2 голосов
/ 10 марта 2009

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

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

    Thread exceptionThread = new Thread(ThrowException);
    exceptionThread.Start();
    exceptionThread.Join();
    //read stream, and rest of the test

Также вы можете установить тайм-аут при соединении.

1 голос
/ 10 марта 2009

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

Для такого рода вещей мы поместим поток чтения внутри цикла (псевдокод): 

while (!timed out) {
    read from stream;
    if (message is in stream) {
        set success flag;
        break;
    }
    sleep;
 }
 if (!success flag) {
     throw test failure;
 }
...