2009-04-19 13 views
22

Nel tentativo di creare un test iniziale dell'unità in prova nelle funzionalità di test di Visual Studio Professonal 2008, non riesco a ottenere Assert.ReferenceEquals() in errore corretto quando un'istanza dell'oggetto è non uguale a uguale a un riferimento null. Notare che object.ReferenceEquals() restituisce correttamente false per questo stesso confronto.Assert.ReferenceEquals() Passa dove Object.ReferenceEquals() restituisce 'false' in Visual Studio Test

Ecco il mio codice della classe:

public static class Project 
{ 
    public static object TheObject { get; set; } 

    public static void Startup(object theObject) 
    { 
     // ToDo: Project.Startup(): Test. 
     // ToDo: Project.Startup(): Implement. 
    } 
} 

E poi qui ci sono gli aspetti chiave della mia classe di test:

[TestClass()] 
public class ProjectTest 
{ 
    [TestMethod()] 
    public void StartupTest() 
    { 
     object obj = "hello"; 
     Project.Startup(obj);  
     Assert.ReferenceEquals(obj, Project.TheObject); // Test Passes!?! 
    } 
} 

Nota che il metodo static void Startup(object) è vuoto, così la proprietà static object TheObject non è mai imposta e rimane null. Quindi, chiaramente, Assert.ReferenceEquals(obj, Project.TheObject) dovrebbe fallire, ma in qualche modo questo test passa.

Nota che cambiando

Assert.ReferenceEquals(obj, Project.TheObject)

a

Assert.IsTrue(object.ReferenceEquals(obj, Project.TheObject))

cause questo test per correttamente sicuro.

Questo sembra troppo semplice, eppure non riesco a vedere cosa sta andando storto qui. Se qualcuno può segnalare l'errore nei miei modi, sarei molto grato.

Grazie in anticipo,

Mike

Aggiornamento Risponde James Avery:

Ah, un modo stupido mi sento ora. I sapeva che doveva essere qualcosa del genere. Wow.

Abbastanza sicuro, "GoToDefinition" mi porta a "Object.ReferenceEquals()". Quindi digitare "Assert.ReferenceEquals()" è in realtà System.Object.ReferenceEquals(), che nel mio caso stava restituendo "false" in modo silenzioso. Questo, ovviamente, non ha nulla a che fare con l'effettiva mancata affermazione, quindi il test supera. Stupefacente.

Grazie James.

+0

Sono appena stato colpito da questo stesso stupido errore. È una trappola così facile in cui cadere. Sembra che le classi di test unitario potrebbero almeno lanciare un avvertimento se non sono state chiamate asserzioni effettive. Questo almeno catturerebbe i casi molto semplici come il tuo codice di esempio sopra e il particolare controllo di proprietà che stavo cercando di realizzare. –

+0

"Sembra che le classi di test unitario potrebbero almeno lanciare un avviso se non sono state chiamate asserzioni effettive." <- Questa è un'idea piuttosto interessante e non solo per proteggere contro questa stupida trappola. Mi piace. –

+2

Un'idea migliore, tuttavia, sarebbe che la classe Assert crei un nuovo metodo statico chiamato "ReferenceEquals" che ombreggi il metodo "Object.ReferenceEquals" e quindi contrassegni quel metodo con ObsoleteAttribute con un messaggio di errore appropriato. In questo modo l'utente verrebbe avvisato se ha commesso questo errore. –

risposta

30

Il metodo ReferenceEquals che si sta chiamando è il metodo statico disponibile su tutti gli oggetti di riferimento, non fa parte del framework di test. Se guardi sta restituendo un valore booleano mentre una normale affermazione sarebbe nulla. Questo è sicuramente fonte di confusione, .AreSame() è l'asserzione che stai cercando.

+1

Ah, che sciocco ora provo. Sapevo * doveva essere qualcosa del genere. Wow. Abbastanza sicuro, "GoToDefinition" mi porta a "Object.ReferenceEquals()". Quindi digitare "Assert.ReferenceEquals()" è in realtà Object.ReferenceEquals(), che nel mio caso stava quietamente restituendo "false" - che, ovviamente, non ha nulla a che fare con l'effettiva mancata affermazione. Quindi il test ** passa **. Stupefacente. Grazie James. –

+1

Mi sono imbattuto in un problema simile e NUnit genera un'eccezione che indica di non utilizzare ReferenceEquals per le asserzioni. L'ho modificato in Assert.AreSame() come suggerito. Ovviamente hanno superato Assert.ReferenceEquals() per generare un'eccezione, ma perché non eseguire l'override della funzione per fare ciò che ci aspettiamo? –