unità test test espliciti a stato variabile in lingue digitate dinamicamente

Question

unità test test espliciti a stato variabile in lingue digitate dinamicamente

#1 da (1 voti)
#2 da (0 voti)

2

Ho sentito dire che una qualità desiderabile dei test unitari è che testano ciascuno scenario indipendentemente. Mi sono reso conto durante la scrittura di test oggi che quando si confronta una variabile con un altro valore in un'istruzione come:

assertEquals("foo", otherObject.stringFoo);

Stai veramente provando tre cose:

La variabile che stai test esiste e rientra nell'ambito.
La variabile che stai testando è di tipo previsto.
Il valore della variabile che stai testando è quello che ti aspetti che sia.

Che per me solleva la questione se testare ognuno di questi in modo implicito in modo che si verifichi un errore di test sulla linea specifica che verifica il problema:

assertTrue(stringFoo);
assertTrue(stringFoo.typeOf() == "String");
assertEquals("foo", otherObject.stringFoo);

Ad esempio se la variabile era un intero invece di una stringa, il fallimento del test case sarebbe sulla linea 2, che ti darebbe più feedback su cosa è andato storto.

Dovresti testare questo tipo di cose in modo esplicito o sto pensando troppo a questo?

unit-testing dynamic-typing

posta Kris Welsh 02.07.2013 - 21:50

fonte

2 risposte

1

Dipende. Molto probabilmente non dovresti usare tre test per qualcosa di così piccolo, e piuttosto usare un debugger se fallisce. Tuttavia, se hai motivo di credere che uno dei primi due casi sarebbe un probabile bug, con tutti i mezzi, inseriscili, se non altro per controllarli tutti.

risposta data 02.07.2013 - 22:03

fonte

Leggi altre domande sui tag unit-testing dynamic-typing

Perché utilizzare i corridori di prova? nucleo di molla scalabile con AMQP?

score 0 · Accepted Answer

La risposta diretta è SÌ, potrebbe essere ancora necessario. Inoltre, per assertEquals stai essenzialmente controllando due cose: tipi e valori, non se esistono. Il motivo è che la funzione mostrerà un errore in un IDE (linea rossa) se uno di questi non è nell'oscilloscopio. HMMMM .... Si può ancora dire che l'uso di un editor di testo piuttosto che di IDE intelligenti non lo dirà, il che è vero. Ma perché non dovresti usarlo in primo luogo? Pertanto, quel test viene eseguito automaticamente anche prima dell'esecuzione del test. Quindi, la tua prima ipotesi circa il% test di verifica di assertEqual per tre cose non è necessariamente corretta: è sicuramente due, potrebbero essere tre. Inoltre, quando dici scope , devi stare attento; lo stesso ambito globale o locale? Quello che sto cercando di dire è questo:

package bla.bla.bla.SomeObject;

class FooTester{
//Global var "foo"
String fooStr = "foo";

@Test
testFoos_Are_They_In_Same_Scope() {
     SomeObject someObject = new someObject();  // Mock object
     String testFooStr = someObject.stringFoo();
     assertEquals(fooStr, testFooStr);
}
}

Chiaramente, foo e testFooStr non sono nello stesso ambito. fooStr è globale e testFooStr è locale.

Un altro buon argomento per avere tre test separati è il seguente:

assertEquals("foo", someObj.stringFoo());

Per una persona che non ha mai fatto alcuna programmazione, ciò significherebbe che stai testando che due stringhe siano uguali o meno. Tuttavia, se hai un test in cui puoi dire:

/* Asserts if the condition is _NOT_ true
assert("THEY ARE NOT AT THE SAME MEMORY LOCATION, BUT MAY HAVE THE SAME VALUE", "foo" == someObj.stringFoo());

Devi capire molto attentamente cosa stai provando a testare e scrivere test con nomi significativi. Se è possibile utilizzare un test per tre casi, fare attenzione durante la scrittura e utilizzare alcuni commenti sensati che dichiarino lo scopo del test (se necessario).

L'ho fatto in passato e lo faccio ancora. La gente mi ha criticato per aver scritto i doppi test, ma non mi ha mai detto di non aver scritto abbastanza test. Paga dividendi a lungo termine.