Test unitari casi banali [duplicati]

2

Attualmente non eseguiamo molti test presso la nostra azienda, ad eccezione di alcuni controlli manuali. Occasionalmente creiamo alcuni test unitari, test di integrazione e test dell'interfaccia utente, ma non su base regolare. Da quando è in corso un nuovo progetto, voglio cogliere l'opportunità per implementare un modo migliore di testare.

Domanda

Dal momento che la maggior parte delle nostre applicazioni Web esegue effettivamente applicazioni di base, molti test sembrano essere banali. E la mia domanda è fondamentalmente, come posso decidere dove disegnare la linea, c'è un approccio per questo. I test unitari di alto livello migliorano la qualità, hanno un costo (sotto forma di scrittura e mantenimento). Per essere concreti, ecco alcuni esempi.

Esempio

Ho un productService con il seguente metodo:

public Product GetProduct(int productId)
{
   return database.GetObject<Product>("select * FROM products wh..",productId)
}

Devo creare un test unitario per questo metodo? Diciamo che lo farei, che sto solo controllando se sto chiamando la query giusta e se sto inoltrando correttamente il parametro productId al livello del database. Questo sembra già un po 'banale. Ma per peggiorare le cose, sto già pensando di creare un test di integrazione per questo metodo per verificare se tutto funziona correttamente insieme, quindi questo test unitario non aggiungerà alcun valore. Ma se seguissi TDD (che è morto, in parte per questo motivo, come ho sentito), allora dovrei creare quel test unitario.

Qualche idea?

    
posta Maarten Kieft 13.11.2016 - 12:41
fonte

1 risposta

3

I'm already planning to create an integration test for this method to check if it all works correctly together so this unit test won't add any value.

Il tuo obiettivo attuale è impedire che il software rotto entri in produzione, non è vero? Il test delle unità è solo uno dei tanti strumenti per raggiungere questo obiettivo. Se il test di integrazione rileva lo stesso errore del test dell'unità, allora è sufficiente per quanto riguarda l'efficacia. Indipendentemente dal modo in cui TDD è determinato a testare tutto, avere quel test unitario specifico non ti farà cogliere ulteriori errori.

Ma per quanto riguarda l'efficienza? Quando il test di integrazione fallisce perché il metodo GetProduct() si è rotto, quanto tempo ci vorrà per raggiungere tale conclusione dai dati forniti dal test di integrazione? Se questo numero è elevato, il costo aggiuntivo di scrittura e mantenimento di una "seconda linea di difesa" potrebbe valerne la pena.

    
risposta data 13.11.2016 - 21:10
fonte

Leggi altre domande sui tag