Como diagnosticar “TestFixtureSetUp falhou”
https://stackoverflow.com/questions/1411676
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Nós usamos TeamCity como nosso servidor CI, e eu só comecei a ver "TestFixtureSetUp Failed" na janela de falha no teste.
Alguma idéia de como eu vou sobre a depuração este problema? Os testes correr bem na minha estação de trabalho (R corredor # teste no VS2008).
Solução
É um pouco de uma falha na implementação de TestFixtureSetUp (e TestFixtureTearDown) que quaisquer exceções não são bem relatados. Eu escrevi a primeira implementação deles e eu nunca consegui-lo para trabalhar da maneira que era suposto. Na época os conceitos no código NUnit foram fortemente acoplado à idéia de que as ações estavam directamente relacionados com um único teste. Assim, o relato de tudo o que estava relacionado com um resultado de teste. Não houve realmente um espaço para relatar algo que aconteceu no nível suíte sem um grande re-escrever (não é uma refatoração quando você mudar uma ovelha em uma escada rolante).
Por causa disso pouco de história é difícil descobrir o que realmente aconteceu em um TestFixtureSetUp. Não é um bom lugar para anexar o erro. A chamada TestFixtureSetUp é um efeito colateral de execução de um teste em vez de ser diretamente relacionado a ele.
@TrueWill tem a idéia certa. Verifique os logs e, em seguida, modificar o teste para adicionar mais logging, se necessário. Você pode querer colocar em try / catch dentro do TestFixtureSetup e log muito no bloco catch. Eu apenas pensei que eu poderia adicionar um pouco de fundo a ele (em outras palavras, é o meu tipo de falha).
Outras dicas
Eu iria verificar Build Log em primeiro lugar.
Se não é óbvio de que, você pode tentar incluindo Console.WriteLines nos testes - Eu não sou positivo, mas eu acho que esses são escritos para Construir Log. Como alternativa, você poderia registrar em um arquivo (mesmo usando log4net se você quiser começar a fantasia).
Se você tiver Visual Studio instalado no servidor CI, você pode tentar executar o build / testes de lá. Se é um problema de conectividade, que pode resolvê-lo.
Já vi problemas de caminho, porém, onde caminhos relativos para arquivos não estavam corretas ou foram utilizados caminhos absolutos. Estas são mais difíceis de depurar e pode exigir o registo dos caminhos e, em seguida, verificar se eles existem no servidor de compilação.
Eu corri para isso hoje ao criar alguns testes de integração que há muito tempo executando a instalação que eu não deseja duplicar. Eu acabei envolvendo toda a lógica de configuração instalação de ensaio de um try / catch. Em seguida, adicione um método de configuração cuja única finalidade é para ver se ocorreu uma falha durante a configuração do dispositivo elétrico e proporcionar um melhor registro.
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);
}
}
Eu estava recebendo o mesmo erro durante a execução de qualquer teste com SpecFlow usando NUnit Visual. Quando eu tentei fazer o mesmo a partir da Unidade de Teste Explorer (fornecido pelo ReSharper), deu uma pequena mensagem mais útil: métodos de ligação com mais de 10 parâmetros não são suportados. Percebi que não pode ter um método SpecFlow com mais de 10 parâmetros, teve que remover o teste.
Eu era capaz de ver que eu não estava criando meu banco de dados de teste corretamente, fazendo uma rápida mudança para VS Unit Testing. No meu caso, foi capaz de retornar uma melhor resposta à razão por que ele falhou. Eu costumo usar NUnit. "Não é possível criar instância de classe X. erro: System.Data.SqlClient.SqlException:. Ocorreu um erro de ativação de arquivo O nome do arquivo físico '\ DbTest.mdf' pode estar incorreta diagnosticar e corrigir erros adicionais, e repita a operação.. CREATE DATABASE falhou. Alguns nomes de arquivo listados não puderam ser criados. Verifique erros relacionados .. "
Executar o teste de unidade em modo de depuração . Você pode encontrar um erro de execução na configuração.
Se você estiver usando SpecFlow e C # no Visual Studio, olhada no arquivo <whatever>.feature.cs gerado automaticamente após o teste falhar. Na linha public partial class <whatever>Feature, você deve ver um símbolo que quando pairava sobre mostrará a razão que a configuração de fixação NUnit falhou. No meu caso, foi que alguns dos meus métodos BeforeFeature na minha classe TestHooks não eram estáticas. Todos os BeforeTestRun, AfterTestRun, BeforeFeature e métodos AfterFeature precisa ser estático.
Eu tive esse problema e ele foi causado pela adição de um Dictionary readonly privada na classe, da mesma maneira que você adicionar um private const string.
Eu tentei fazer o Dictionary uma constante, mas você não pode fazer isso em tempo de compilação. Eu resolvi isso colocando meu Dictionary em um método que retorna.
Eu tive esse sintoma causado por um erro durante a inicialização do campo. Se o seu initialize seus campos no método [SetUp], você deve ver uma mensagem de erro melhor.
[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(...);
}
...
}
Eu estava preocupado com isso hoje. Eu fiz o seguinte para obter o erro real.
(1) Adicione outro teste em um dispositivo separado, que inicializa um exemplo do dispositivo de ensaio perturbando, chama explicitamente métodos adicionais, tais como TestFixtureSetUp e configuração Se qualquer, e, em seguida, executa o método de ensaio-alvo.
(2) Adicionar manipulação de exceção código para o novo código acima, e log / saída a exceção real para algum lugar.
Em caso pode ajudar alguém: Você pode capturar a exceção e escrevê-lo no console no TearDown
Algo como:
[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));
}
}
}
E o resultado será:
TestFixtureSetUp falhou em IntegratedTests.Services.BaseTest - De propósito
