Definizione dei test di unità fragili

Naviga le tue risposte
3

Ho visto i termini fragili e fragili usati per descrivere i test unitari scritti male. Ma non sono stato in grado di trovare una definizione chiara di ciò che in realtà è fragile o fragile in questo contesto.

  • Sono i test unitari che si interrompono per più di un motivo?
  • È quando un test fallisce perché qualcosa nel codice base viene cambiato questo è apparentemente estraneo al test?
  • Vengono verificati test delle funzionalità in modo inappropriato, come testare come invece di cosa funzioni una funzione?
  • Qualcosa di completamente diverso?

O questi termini sono semplicemente una cover-all per tutti gli odori unit test?

    
posta Ayb4btu 25.08.2017 - 03:47
fonte

1 risposta

11

I termini "fragile" e "fragile" non hanno una definizione chiara e specifica nel contesto dello sviluppo del software. Sono piuttosto parole comuni in inglese che a volte vengono utilizzate nello sviluppo di software per descrivere determinati tipi di codice.

Nel contesto dello sviluppo del software, queste parole significano esattamente la stessa cosa che fanno ovunque: le cose "fragili" e "fragili" sono cose facili da rompere.

Detto questo, c'è questo "saggio di riflessione personale" da Wikipedia . Se stai cercando una definizione "ufficiale", questa è valida come qualsiasi:

Software brittleness is the increased difficulty in fixing older software that may appear reliable, but fails badly when presented with unusual data or altered in a seemingly minor way.

Cose che rendono i test unitari fragili:

  1. Asserimento contro elementi in un'interfaccia utente.
  2. Asserimento contro stringhe di risultato di grandi dimensioni anziché valori discreti.
  3. Stato statico o condivisione dello stato impropria tra i thread.
  4. Dati di test non realistici o altrimenti inadeguati
  5. Elaborare schemi di derisione.
  6. Codice fragile sotto test.
  7. Troppi casi limite o complessità ciclomatica irragionevolmente alta.
  8. Troppe responsabilità.
  9. Astrazioni di perdita.
  10. Il codice sotto test non è idempotente tra le sessioni di test.
  11. Test i cui risultati possono variare in base all'ambiente, ad esempio i tempi di esecuzione.
  12. Test che non possono essere eseguiti indipendentemente l'uno dall'altro.

Come puoi vedere, ciò che rende i test di unità fragili spesso è non l'errore del test, ma l'errore del codice in fase di test.

Un modo per avere test migliori (e per estensione, codice migliore), è fare pratica di sviluppo in prova. Scrivere i test prima ti costringe a pensare alla superficie dell'API del tuo codice, e ti incoraggia caldamente a scrivere quella superficie in modo da renderla più semplice, più robusta, più deterministica e più facile da testare.

Ulteriori letture
The Brittleness of Unit Test
Qualche buon consiglio per i neofiti ai test unitari

    
risposta data 25.08.2017 - 04:23
fonte

Leggi altre domande sui tag

Rappresentare uno stato come stringhe a lettera singola [duplicato] Il test di integrazione dovrebbe offrire più valore dei test unitari? [duplicare]