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

Ответ 1

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

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

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

Ответ 2

Я бы сначала проверил журнал сборки.

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

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

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

Ответ 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);
    }
 }

Ответ 4

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

У меня была эта проблема, и это было вызвано добавлением в класс приватного readonly Dictionary, подобно тому, как вы добавляете private const string.

Я попытался сделать константу Dictionary константой, но вы не можете сделать это во время компиляции. Я решил это, поместив мой Dictionary в метод, который возвращает его.

Ответ 9

У меня был этот симптом, вызванный ошибкой во время инициализации поля. Если вы инициализируете свои поля в методе [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(...);
    }
    ...
}

Ответ 10

Меня это беспокоило сегодня. Для получения фактической ошибки я сделал следующее.

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

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

Ответ 11

В случае, если это может помочь кому-то: Вы можете поймать исключение и записать его в консоли на 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 - в целях