Crea test Junit per un metodo che copre tutte le sue invocazioni nello spazio di lavoro Eclipse

Question

Consente di assumere la seguente classe Java:

class MyClass {
   public String methodA( String data, String expression ) {
      // expression is evaluated using data
      // ...
      // this leads to a result which is returned
      return result;
   }
}

.

Nota, che expression è un'istanza di un linguaggio di espressione (DSL). Pertanto, la valutazione di expression utilizzando data dipende dalla combinazione di entrambi. Normalmente, expression è un valore fisso che non cambia spesso e data può cambiare in tutte le invocazioni.

Bene, a volte in seguito viene trovato un bug in MyClass.methodA(String,String). Il bug risiede in una classe sottostante e si verifica solo per una combinazione speciale di expression e data. Un test di Junit è facilmente scritto per questo caso speciale e può essere risolto.

Sfortunatamente, questo metodo è usato frequentemente attraverso l'intero progetto. Eclipse Call Gerarchy identifica più di 97 altri metodi in cui viene utilizzato questo metodo. Ora temono la regressione, se applichiamo solo il bugfix. Per sentirsi più sicuro, mi piacerebbe fare alcuni test di regressione.

Normalmente, i test unitario dovrebbero prendere in considerazione tutti i tipi importanti di invocazioni, in particolare i casi di confine. Ma, poiché expression è un DSL che può variare altamente, non è facile testare il test-coprire tutti i potenziali utilizzo. Inoltre, tali test non identificherebbero falsi utilizzo facendo affidamento sul bug.

Quindi la mia idea è di procedere nel modo seguente:

.

1. Trova tutte le invocazioni di questo metodo (come usare "Gerarchia di chiamata" in eclipse) ed estrarre tutti i valori per expression.

2. Campioni sufficienti valori di vita reale per data (ad esempio dal database) ea valutazione incrociata Tutte le espressioni dal primo passo con la versione originale di MyClass.methodA(String,String). Salva le triple (data, expression, result) in un file.

3. Implementare bugfix.

4. Metodo di prova MyClass.methodA(String,String) utilizzando il file sopra riportato per affermare che i risultati non sono stati modificati.

   seguenti domande :

   Cosa ne pensi di questo approccio?

   Utilizzo della gerarchia di chiamata in eclipse Posso solo copiare e incollare i metodi di chiamata ma non l'invocazione esatta che include argomenti negli Appunti (cfr. Passaggio 1). Dovrei copiare la chiamata invocatura a mano per ogni metodo trovato. Come estrarre le invocazioni in modo conveniente (nell'area di lavoro Eclipse completa, quindi in diversi progetti)?

   IMHO I Sto solo testando un singolo metodo, quindi i test coprono solo un'unica unità. Va bene usare junit per il passaggio 4 o c'è qualcosa di più sofisticato?

Answer 1

Come il valore aggiuntivo previsto testando il tuo software è quello di coprire la maggior parte delle circostanze con i costi più bassi e il risultato massimo, sarei d'accordo con il tuo approccio.

Raccolta Reallife Samplevalues dal tuo software e salvarli in un file rappresentativo non dovrebbe essere quel complesso per realizzare e mi sembra come il modo migliore per analizzare questa cosa.Anche se devi copiarlo manualmente.