Supponiamo che tu abbia una proprietà startTime . Allora hai un metodo doSomething :
doSomething() {
//...stuff
startTime = System.currentTimeMillis();
//... more stuff
}
Come fai a verificare che startTime sia stato assegnato correttamente? Non puoi testare un timestamp assoluto: probabilmente cambierà tra assegnazione e test. Forse usare un intervallo?
Un modo semplice è passare il tempo dall'esterno del metodo:
doSomething(long currentTime) {
//...stuff
startTime = currentTime;
//... more stuff
}
Il tuo codice di produzione che chiama il metodo può passare nel valore reale per System.currentTimeMillis (), mentre i tuoi test di unità possono passare in uno specifico valore noto.
Naturalmente, questo non è esattamente lo stesso del tuo originale. Un'altra possibilità è un po 'più complessa, ma dovrebbe simulare il comportamento del tuo originale più da vicino:
doSomething(ITimeGetter timeGetter) {
//...stuff
startTime = timeGetter.GetCurrentTime;
//... more stuff
}
Definisci l'interfaccia:
interface ITimeGetter
{
long GetCurrentTime();
}
Due implementazioni, una per il codice di produzione:
class RealTimeGetter implements ITimeGetter
{
long GetCurrentTime()
{
return System.currentTimeMillis();
}
}
Uno per i test di unità:
class TimeGetterForTests implements ITimeGetter
{
long GetCurrentTime()
{
// return a known value.
}
}
Crea un'istanza ITime appropriata al tuo scenario e passa al metodo che vuoi testare.
Martin Fowler ha appena scritto un interessante blog post sui test che potrebbero non riuscire. Scrive anche su come dovresti gestire il tempo, cioè avvolgendo la chiamata di sistema in un oggetto separato.
In generale, quando comunichi con risorse esterne, per test e incapsulamento, aiuta sempre a raggrupparle in oggetti.
Devi astrarre il meccanismo del timestamp in modo da poterlo prendere in giro.
Ciò ti consentirà di generare esattamente i risultati di currentTimeMillis necessari per il test, così puoi essere certo che i valori siano corretti.
Leggi altre domande sui tag unit-testing time