Как диагностировать «TestFixtureSetUp Failed»

Question

Мы используем TeamCity в качестве нашего CI-сервера, и я только начал видеть "TestFixtureSetUp Failed" в окне сбоя теста.

Есть идеи, как мне отладить эту проблему? На моей рабочей станции тесты проходят нормально (R # test runner в VS2008).

Answer 1

В реализации TestFixtureSetUp (и TestFixtureTearDown) есть небольшой недостаток, заключающийся в том, что о каких-либо исключениях не сообщается. Я написал их первую реализацию, и я так и не смог заставить ее работать так, как предполагалось. В то время концепции в коде NUnit были тесно связаны с идеей, что действия были напрямую связаны с одним тестом. Таким образом, отчетность обо всем была связана с результатом теста. На самом деле не было места для сообщения о том, что произошло на уровне комплекта, без огромного переписывания (это не рефакторинг, когда вы превращаете овцу в эскалатор).

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

@ TrueWill имеет правильную идею. Проверьте журналы, а затем измените тест, чтобы добавить дополнительные журналы при необходимости. Возможно, вы захотите поместить в try / catch внутри TestFixtureSetup и много регистрировать в блоке catch. Я просто подумал, что мог бы добавить к этому некоторую предысторию (другими словами, это своего рода моя вина).

Answer 2

Сначала я проверю журнал сборки.

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

Если на CI-сервере установлена ​​Visual Studio, вы можете попробовать запустить сборку / тестирование оттуда. Если это проблема с подключением, это может решить ее.

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

Answer 3

Я столкнулся с этим сегодня, когда создавал некоторые интеграционные тесты, которые долго выполнялись, и которые я не хочу дублировать. В итоге я обернул всю логику настройки тестового прибора в try / catch. Затем я добавляю метод SetUp, единственная цель которого состоит в том, чтобы увидеть, произошел ли сбой во время настройки устройства, и обеспечить лучшее ведение журнала.

Exception testFixtureSetupException = null;

[TestFixtureSetUp]
public void FixtureSetup()
{
    try
    {
        // DoTestFixtureSetup
    }
    catch (Exception ex)
    {
        testFixtureSetupException = ex;
    }
}

[SetUp]
// NUnit doesn't support very useful logging of failures from a TestFixtureSetUp method. We'll do the logging here.
public void CheckForTestFixturefailure()
{         
    if (testFixtureSetupException != null)
    {
        string msg = string.Format("There was a failure during test fixture setup, resulting in a {1} exception. You should check the state of the storage accounts in Azure before re-running the RenewStorageAccountE2ETests. {0}Exception Message: {3}{0}Stack Trace:{4}",
            Environment.NewLine, testFixtureSetupException.GetType(), accountNamePrefix, testFixtureSetupException.Message, testFixtureSetupException.StackTrace);
        Assert.Fail(msg);
    }
 }

Answer 4

Если вы используете SpecFlow и C # в Visual Studio, посмотрите на автоматически сгенерированный файл <whatever>.feature.cs после сбоя теста. В строке public partial class <whatever>Feature вы должны увидеть символ, который при наведении курсора покажет причину сбоя установки прибора NUnit. В моем случае некоторые мои BeforeFeature методы в моем классе TestHooks не были статичными. Все методы BeforeTestRun, AfterTestRun, BeforeFeature и AfterFeature должны быть статическими.

Answer 5

Запустить модульное тестирование в режиме отладки . Вы можете найти ошибку времени выполнения в настройках.

Answer 6

Я смог убедиться, что не правильно создавал свою тестовую базу данных, быстро переключившись на VS Unit Testing. В моем случае он смог лучше ответить на причину, по которой это не удалось. Я обычно использую NUnit. "Невозможно создать экземпляр класса X. Ошибка: System.Data.SqlClient.SqlException: произошла ошибка активации файла. Физическое имя файла '\ DbTest.mdf' может быть неправильным. Диагностируйте и исправьте дополнительные ошибки и повторите операцию. СОЗДАТЬ БАЗУ ДАННЫХ не удалось. Некоторые имена файлов не могут быть созданы. Проверьте связанные ошибки. «

Answer 7

Я получал ту же ошибку при запуске любого теста с SpecFlow с использованием Visual NUnit. Когда я попытался сделать то же самое из Unit Test Explorer (предоставленного Resharper), он выдал немного более полезное сообщение: методы привязки с более чем 10 параметрами не поддерживаются. Я понял, что у меня не может быть метода SpecFlow с более чем 10 параметрами, пришлось удалить тест.

Answer 8

В случае, если это может кому-то помочь: Вы можете поймать исключение и записать его в консоли на TearDown

Что-то вроде:

[SetUpFixture]
public class BaseTest
{
    private Exception caughtException = null;

    [SetUp]
    public void RunBeforeAnyTests()
    {
        try
        {
            throw new Exception("On purpose");
        }
        catch (Exception ex)
        {
            caughtException = ex;               
        }
    }

    [TearDown]
    public void RunAfterAnyTests()
    {
        if (caughtException != null)
        {
            Console.WriteLine(string.Format("TestFixtureSetUp failed in {0} - {1}", this.GetType(), caughtException.Message));
        }           
    }

}

И результат будет:

Сбой TestFixtureSetUp в IntegratedTests.Services.BaseTest - специально

Answer 9

Я был обеспокоен этим сегодня. Я сделал следующее, чтобы получить фактическую ошибку.

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

(2) Добавьте код обработки исключений для нового кода выше и зарегистрируйте / выведите фактическое исключение куда-нибудь.

Answer 10

У меня был этот симптом, вызванный ошибкой во время инициализации поля. Если вы инициализируете свои поля методом [SetUp], вы должны увидеть лучшее сообщение об ошибке.

[TestFixture]
internal class CommandParserTest
{
    // obscure error message
    private CommandParser parser = new CommandParser(...);
    ...
}

[TestFixture]
internal class CommandParserTest
{
    private CommandParser parser;

    [SetUp]
    public void BeforeTest()
    {
        // better error message
        parser = new CommandParser(...);
    }
    ...
}