Test unità di Visual Studio: perché il test non funziona mentre analizza gli stessi valori float?

Sto imparando prova VS Unità e provato questo:Test unità di Visual Studio: perché il test non funziona mentre analizza gli stessi valori float?

[TestMethod()] 
    public void calcTest() 
    { 
     double expected = 1.234F; // TODO: Initialize to an appropriate value 
     double actual; 
     actual = 1.234F; 
     Assert.AreEqual(expected, actual); 
     Assert.Inconclusive("Verify the correctness of this test method."); 
    }

Durante l'esecuzione di questo metodo di prova, si dice inconcludente ??? Perché ?

Aggiornamento: Ciao Ragazzi ok per dire non confrontare i float ma i requisiti aziendali sono quello che sono, quindi cosa dovrei fare se ho bisogno di confrontarli?

Intendi dire che è impossibile testare il calcolo fluttuante senza mal di testa? Quindi, se il test è un tale mal di testa nel calcolo finanziario, non è meglio non testare affatto?

sembra un enorme bug o difetto di progettazione nel quadro vs test piuttosto :) come si dice qui http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.assert.inconclusive%28VS.80%29.aspx

indica che un affermazione non può essere provata vera o falsa.

Dato che paragono 2 litterali uguali, è vero!

fonte

2010-09-23 user310291

La suite di test di unità Microsoft ora comprende anche metodi di overload per testare carri allegorici (e raddoppia) passando in una tolleranza delta che indica "quanto sono uguali" i valori che devono essere passati (http://msdn.microsoft.com/en-us/library/ms243456.aspx). Utilizzato in questo modo: 'Assert.AreEqual (float expected, float actual, float delta, string failingTestMessage)' – Spiralis

erm, perché hai detto di essere?

Assert.Inconclusive("Verify the correctness of this test method.");

Ora avete il vostro AreEqual, si dovrebbe essere in grado di rimuovere questo Inconclusive

Qualsiasi errore durante un test (non incluse le eccezioni che si intenzionalmente maniglia) è generalmente terminale, ma qualsiasi affermano che passa (come lo AreEqual qui) continua a correre. Quindi passa il primo test, quindi l'ultima riga lo contrassegna come inconcludente.

fonte

2010-09-23 11:47:13

Why Assert.Conclusive non esiste? Non stiamo facendo test statistici laddove tale inconcludenza sarebbe sensata, questo è un test deterministico in cui il risultato del test sarà sì o no. – user310291

Penso che tu abbia ragione, ma il modello non dovrebbe inserire questo come predefinito nello snippet di codice perché questo è molto confuso. – user310291

@ user310291 da una prospettiva di test, questo non è fonte di confusione. Tutti i test falliscono fino a quando non si scrive il test corretto (e si rimuove la parte inconcludente) o si corregge il codice da testare. –

Questo non significa solo che il AreEqual è passato, il che significava che si chiamava Assert.Inconclusive, portando a un risultato inconcludente?

Da the docs:

Simile a fallire in quanto indica un'asserzione è inconcludente senza verifica alcuna condizione.

Se non si desidera che il risultato sia inclusiva, rimuovere la chiamata a Assert.Inconclusive :)

fonte

2010-09-23 11:47:25

Il mio punto è matematicamente e dal punto di vista aziendale è sicuramente non inconcludente ma determinante poiché è vero :) – user310291

Assert.Inclusivo Metodo Indica che un'asserzione non può essere dimostrata vera o falsa. – user310291

secondo http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.assert.inconclusive%28VS.80%29.aspx – user310291

Anche quando hai rimosso il Assert.Inconclusive ancora potrebbe avere problemi.

si sta testando l'uguaglianza di due numeri in virgola mobile e in generale, con valori calcolati non sarai mai farli esattamente lo stesso. È necessario verificare che il valore effettivo rientri in un intervallo accettabile del valore previsto:

Math.Abs(actual - expected) < 0.00001;

per esempio.

Il tuo Assert.AreEqual(expected, actual); funziona in questo caso perché si assegna lo stesso valore a entrambe le variabili.

fonte

2010-09-23 11:49:21 ChrisF

Buon avvertimento, ma in questo caso sta confrontando due variabili inizializzato da letterali, quindi mi aspetterei * che sia OK. Ma +1, sicuramente un ottimo punto da rilanciare! –

@Marc - Ho notato che ha aggiunto una nota in tal senso. – ChrisF

Il fatto che esatte rappresentazioni in virgola mobile esatte per determinati numeri decimali non li rende "sfocati". Il punto generale su non confrontare 2 float per l'uguaglianza va bene, ma non si applica in questo caso: non vi è alcuna ragione per cui il compilatore sceglierà diverse rappresentazioni 'doppie' per lo stesso * letter * float'. – Ani

L'UnitTest automatico viene generato da VS e indica di creare alcune operazioni da confrontare. se commenterai l'ultimo comando Assert otterrai "Passato" con il segno verde, ma non l'hai verificato.
È necessario, come nel commento, "Inizializza su un valore appropriato" e come nell'ultima Assert "Verifica la correttezza di questo metodo di prova".
Inizializzare i valori previsti e quelli effettivi da dove provengono da ad esempio, Previsto è il valore previsto dalla funzione Aggiungi (x, y) dove x = 2 ey = 3. Il valore effettivo dovrebbe provenire dalla funzione. in questo caso:

// Sample - Start 
Expected = 2+3; 
Actual = Add(2,3); 
Assert.AreEqual(expected, actual); 
// Sample - End

Speranza ha aiutato, ho rotto pochi denti per questo ... ;-)

fonte

2012-10-16 09:14:30 Shikeh

Test unità di Visual Studio: perché il test non funziona mentre analizza gli stessi valori float?

risposta

Problemi correlati