Come diagnosticare "TestFixtureSetUp non riuscito"
https://stackoverflow.com/questions/1411676
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Usiamo TeamCity come nostro server CI e ho appena iniziato a vedere " TestFixtureSetUp Failed " nella finestra del fallimento del test.
Hai idea di come faccio a eseguire il debug di questo problema? I test funzionano bene sulla mia workstation (test runner R # in VS2008).
Soluzione
È un po 'un difetto nell'implementazione di TestFixtureSetUp (e TestFixtureTearDown) che eventuali eccezioni non siano ben segnalate. Ho scritto la loro prima implementazione e non l'ho mai fatto funzionare come doveva. All'epoca i concetti nel codice NUnit erano strettamente accoppiati all'idea che le azioni fossero direttamente correlate a un singolo test. Quindi la segnalazione di tutto era correlata a un risultato del test. Non c'era davvero spazio per segnalare qualcosa accaduto a livello di suite senza un'enorme riscrittura (non è un refactoring quando si cambia una pecora in una scala mobile).
A causa di quel po 'di storia, è difficile scoprire cosa è realmente accaduto in TestFixtureSetUp. Non esiste un buon posto per allegare l'errore. La chiamata TestFixtureSetUp è un effetto collaterale dell'esecuzione di un test invece di essere direttamente correlato ad esso.
@TrueWill ha l'idea giusta. Controllare i registri e quindi modificare il test per aggiungere altra registrazione, se necessario. Potresti voler mettere a try / catch all'interno di TestFixtureSetup e accedere molto al blocco catch. Ho solo pensato di poter aggiungere qualche sfondo ad esso (in altre parole è un po 'colpa mia).
Altri suggerimenti
Prima controllerei il registro di costruzione.
Se non è ovvio da ciò, potresti provare a includere Console.WriteLines nei test: non sono positivo, ma penso che siano scritti nel registro di build. In alternativa puoi accedere a un file (anche usando log4net se vuoi essere sofisticato).
Se Visual Studio è installato sul server CI, è possibile provare a eseguire build / test da lì. Se si tratta di un problema di connettività, potrebbe risolverlo.
Tuttavia, ho riscontrato problemi di percorso in cui i percorsi relativi ai file non erano più corretti o venivano utilizzati percorsi assoluti. Questi sono più difficili da eseguire il debug e potrebbero richiedere la registrazione dei percorsi e quindi verificare se esistono sul server di build.
Oggi mi sono imbattuto in questo durante la creazione di alcuni test di integrazione che hanno una configurazione di lunga durata che non voglio duplicare. Ho finito per avvolgere tutta la logica di configurazione del dispositivo di prova in un tentativo / cattura. Aggiungo quindi un metodo SetUp il cui unico scopo è vedere se si è verificato un errore durante l'installazione del dispositivo e fornire una migliore registrazione.
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);
}
}
Stavo ottenendo lo stesso errore durante l'esecuzione di qualsiasi test con SpecFlow utilizzando Visual NUnit. Quando ho provato a fare lo stesso da Unit Test Explorer (fornito da Resharper), mi ha dato un messaggio un po 'più utile: i metodi di associazione con più di 10 parametri non sono supportati. Mi sono reso conto che non posso avere un metodo SpecFlow con più di 10 parametri, ho dovuto rimuovere il test.
Sono stato in grado di vedere che non stavo creando correttamente il mio database di test facendo un rapido passaggio a VS Unit Testing. Nel mio caso è stato in grado di restituire una risposta migliore al motivo per cui ha fallito. Di solito uso NUnit. " Impossibile creare l'istanza della classe X. Errore: System.Data.SqlClient.SqlException: si è verificato un errore di attivazione del file. Il nome del file fisico '\ DbTest.mdf' potrebbe non essere corretto. Diagnosticare e correggere errori aggiuntivi e riprovare a eseguire l'operazione. CREATE DATABASE non riuscito. Non è stato possibile creare alcuni nomi di file elencati. Verifica errori correlati. & Quot;
Esegui il test unitario in modalità debug . È possibile che si sia verificato un errore di runtime nell'installazione.
Se stai usando SpecFlow e C # in Visual Studio, guarda il file generato automaticamente < qualunque sia > .feature.cs dopo che il test fallisce. Nella riga public partial class < qualunque cosa > Feature , dovresti vedere un simbolo che, quando passa con il mouse sopra, mostrerà il motivo per cui l'installazione del dispositivo NUnit non è riuscita. Nel mio caso, alcuni dei miei metodi BeforeFeature nella mia classe TestHooks non erano statici. Tutti i metodi BeforeTestRun , AfterTestRun , BeforeFeature e AfterFeature devono essere statici.
Ho riscontrato questo problema ed è stato causato dall'aggiunta di un Dizionario di sola lettura nella classe, più o meno allo stesso modo in cui si aggiunge una stringa const privata .
Ho provato a rendere il Dizionario una costante ma non puoi farlo al momento della compilazione. Ho risolto questo problema inserendo il mio Dizionario in un metodo che lo restituiva.
Ho avuto questo sintomo causato da un errore durante l'inizializzazione del campo. Se inizializzi i campi nel metodo [SetUp] , dovresti visualizzare un messaggio di errore migliore.
[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(...);
}
...
}
Sono stato turbato da questo oggi. Ho fatto quanto segue per ottenere l'errore reale.
(1) Scrivere un altro test in un dispositivo separato che inizializza un'istanza del dispositivo di test problematico, chiama in modo esplicito metodi di installazione come TestFixtureSetUp e SetUp se presenti, quindi esegue il metodo di test di destinazione.
(2) Aggiungi il codice di gestione delle eccezioni per il nuovo codice sopra e registra / genera l'eccezione effettiva da qualche parte.
Nel caso in cui possa aiutare qualcuno: Puoi prendere l'eccezione e scriverla nella console su TearDown
Qualcosa del tipo:
[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 il risultato sarà:
TestFixtureSetUp non riuscito in IntegratedTests.Services.BaseTest - A proposito
