Quali sono gli svantaggi dei test automatici?

Hai praticamente inchiodato i più importanti. Ho alcune aggiunte minori, oltre allo svantaggio dei test effettivamente riusciti - quando non li vuoi davvero (vedi sotto).

• Tempo di sviluppo: con lo sviluppo basato su test, questo è già calcolato per i test unitari, ma sono comunque necessari test di integrazione e di sistema, che potrebbero richiedere anche il codice di automazione. Il codice scritto una volta viene solitamente testato in più fasi successive.

• Livello di abilità: ovviamente, gli strumenti devono essere supportati. Ma non è solo la tua squadra. In un progetto più ampio potresti avere un team di test separato che scrive test per verificare le interfacce tra il prodotto del tuo team e le altre. Tante altre persone devono avere più conoscenza.

• Esigenze di strumenti: sei proprio lì. Non c'è molto da aggiungere a questo.

• Test falliti: questo è il vero bugger (per me comunque). Ci sono un sacco di motivi diversi, ognuno dei quali può essere visto come uno svantaggio. E il più grande svantaggio è il tempo necessario per decidere quale di questi motivi si applica effettivamente al tuo test fallito.

  • fallito, a causa di un bug reale. (solo per completezza, poiché questo è ovviamente vantaggioso)
  • non riuscito, perché il tuo codice di test è stato scritto con un bug tradizionale.
  • non riuscito, perché il tuo codice di prova è stato scritto per una versione precedente del tuo prodotto e non è più compatibile
  • non riuscito, poiché i requisiti sono stati modificati e il comportamento testato è ora considerato "corretto"

• Test non falliti: anche questi sono uno svantaggio e possono essere piuttosto negativi. Succede soprattutto quando cambi le cose e si avvicina a ciò che Adam ha risposto. Se modifichi qualcosa nel codice del tuo prodotto, ma il test non lo tiene affatto conto, allora ti dà questo "falso senso di sicurezza".

  Un aspetto importante dei test non falliti è che una modifica dei requisiti può portare a un comportamento precedente a diventare non valido. Se disponi di una tracciabilità decente, la modifica dei requisiti dovrebbe essere compatibile con il tuo codice di prova e sai che non puoi più fidarti di quel test. Naturalmente, mantenere questa tracciabilità è ancora un altro svantaggio. E se non lo fai, finisci con un test che non fallisce, ma in realtà verifica che il tuo prodotto funzioni erroneamente . Da qualche parte lungo la strada questo ti colpirà ... di solito quando / dove meno te l'aspetti.

• Costi di implementazione aggiuntivi: non esegui solo unit test come sviluppatore sul tuo computer. Con i test automatici, si desidera eseguirli su commit da altri in un posto centrale per scoprire quando qualcuno ha rotto il tuo lavoro. Questo è bello, ma deve anche essere impostato e gestito.

Avendo appena iniziato a provare i test automatici nel nostro team, il più grande svantaggio che ho visto è che è molto difficile applicare a un codice legacy che non è stato progettato pensando ai test automatici. Migliorerebbe indubbiamente il nostro codice a lungo termine, ma il livello di refactoring necessario per i test automatizzati, pur mantenendo il nostro equilibrio mentale, rappresenta una barriera molto elevata per l'ingresso a breve termine, il che significa che dovremo essere molto selettivi sull'introduzione automatizzata test unitario per soddisfare i nostri impegni a breve termine. In altre parole, è molto più difficile pagare le carte di credito quando hai già un debito tecnico profondo.

Forse lo svantaggio più importante è ... i test sono codice di produzione . Ogni test che scrivi aggiunge un codice al tuo codice base che deve essere mantenuto e supportato. Non riuscirci porta a test a cui non credi, quindi non hai altra scelta. Non fraintendermi - Sono un grande sostenitore dei test automatici. Ma tutto ha un costo, e questo è un grande.

Non direi che questi sono svantaggi del tutto applicabili, ma i pochi che ho colpito di più sono:

• Tempo necessario per impostare il test in un'applicazione enterprise complessa.
• Gestendo vecchi test che non funzionano correttamente, in altre parole, il sistema si è evoluto e ora i test sono sbagliati.
• Falsa confidenza con la copertura di test irregolare o sconosciuta.

La copertura del test che è irregolare può portare a un falso senso di sicurezza. Se fai un refactoring e usi i test per dimostrarne la validità, cosa ha dimostrato che i tuoi test sono in grado di dimostrarlo?

Il tempo necessario per creare il test a volte è un problema per noi. I nostri test automatici non includono solo test unitari, ma utilizzano anche test di casi. Questi tendono ad essere più ampi e richiedono un contesto.

Naturalmente, la mia prospettiva proviene da un'applicazione più vecchia dei suoi test unitari.

Direi che il problema principale con loro è che possono fornire un falso senso di sicurezza . Solo perché hai dei test unitari, ciò non significa che in realtà sono fare qualsiasi cosa e questo include testare correttamente i requisiti.

Inoltre, i test automatici possono anche includere bug stessi , in modo che porti la domanda su se i test unitari hanno bisogno di testare se stessi quindi non necessariamente ottenere alcun risultato.

Sebbene i test di automazione abbiano molti vantaggi, hanno anche i suoi stessi svantaggi. Alcuni degli svantaggi sono:

• È richiesta competenza per scrivere gli script di test di automazione.
• Il debug dello script di test è un grosso problema. Se qualche errore è presente nello script di test, a volte può portare a conseguenze mortali.
• La manutenzione del test è costosa in caso di metodi di riproduzione. Anche se nella GUI si verifica un cambiamento minore, lo script di test deve essere registrato di nuovo o sostituito da un nuovo script di test.
• La manutenzione dei file di dati di test è difficile, se lo script di test verifica più schermate.

Alcuni degli svantaggi di cui sopra spesso sottraggono al vantaggio ottenuto dagli script automatici. Sebbene i test di automazione abbiano vantaggi e limiti, è adattato ampiamente in tutto il mondo.

Recentemente ho chiesto a una domanda sui test nello sviluppo del gioco - questo è il modo in cui sapevo di questo. Le risposte là hanno indicato alcuni svantaggi specifici e curiosi:

1. È costoso fare quando il codice dovrebbe essere altamente accoppiato .
2. È difficile da fare quando devi essere a conoscenza delle varie piattaforme hardware, quando devi analizzare l'output per l'utente e il codice il risultato ha senso solo in un contesto più ampio .
3. I test UI e UX sono molto difficili .
4. In particolare, i test automatici possono essere più costosi e meno efficaci di un gruppo di beta tester a basso costo (o gratuiti) .

Il 4 ° punto mi fa ricordare una mia esperienza. Ho lavorato in una società gestita da Scrum molto snella, orientata all'XP, dove i test unitari erano altamente raccomandati. Tuttavia, nel suo percorso verso uno stile più snello e meno burocratico, l'azienda ha semplicemente trascurato la costruzione di un team di controllo qualità: non avevamo tester. Molto spesso i clienti hanno trovato bug insignificanti utilizzando alcuni sistemi, anche con una copertura di test di > 95%. Quindi aggiungerei un altro punto:

• Test automatici possono farti sentire che il controllo qualità e i test non sono importanti.

Inoltre, stavo pensando a quei giorni sulla documentazione e ho cogitato un'ipotesi che potrebbe essere valida (in misura minore) ai test due. Ho appena sentito che il codice si evolve così rapidamente che è piuttosto difficile creare una documentazione che segua una tale velocità, quindi è più prezioso dedicare del tempo a rendere il codice leggibile piuttosto che scrivere documentazione pesante e obsoleta. (Naturalmente, questo non si applica alle API, ma solo all'implementazione interna.) Il test soffre un po 'dello stesso problema: potrebbe essere troppo lento per scrivere rispetto al codice testato. OTOH, è un problema minore perché i test avvertono che sono obsoleti, mentre la tua documentazione rimarrà silenziosa finché non la rileggierai molto, molto attentamente .

Infine, un problema che trovo a volte: i test automatici possono dipendere dagli strumenti e questi strumenti potrebbero essere scritti male. Ho iniziato un progetto usando XUL qualche tempo fa e, uomo, questo è solo doloroso scrivere test di unità per tale piattaforma. Ho iniziato un'altra applicazione usando Objective-C, Cocoa e Xcode 3 e il modello di test su di esso era fondamentalmente un mucchio di soluzioni alternative.

Ho altre esperienze sugli svantaggi dei test automatici, ma la maggior parte di essi sono elencati in altre risposte. Nondimeno, sono un sostenitore veemente dei test automatizzati. Ciò ha risparmiato un sacco di lavoro e mal di testa e lo raccomando sempre per impostazione predefinita. Giudico che questi svantaggi sono solo semplici dettagli rispetto ai benefici dei test automatici. (È importante sempre proclamare la tua fede dopo aver commentato le eresie per evitare l'auto da fé.)

Due che non sono menzionati sono:

• La durata del tempo necessario per eseguire una suite di test di grandi dimensioni

Ho fatto parte degli sforzi automatizzati di controllo della qualità in cui è stata necessaria una mezza giornata per eseguire i test, perché i test erano lenti. Se non stai attento a scrivere i tuoi test, anche la tua suite di test potrebbe risultare in questo modo. Questo non sembra un grosso problema fino a quando non gestisci quella volta, "Oh, ho appena commesso una correzione, ma ci vorranno 4 ore per dimostrare la correttezza".

• La fragilità di alcuni metodi di scrittura del test

Alcuni metodi di test (come l'automazione dell'interfaccia utente) sembrano rompersi ogni volta che ti giri. Particolarmente doloroso se il tuo script, ad esempio, blocca il processo di test perché è in attesa della comparsa di un pulsante, ma il pulsante è stato rinominato.

Queste sono entrambe le cose su cui puoi lavorare, con una buona pratica di test: trova i modi per mantenere la tua suite di test veloce (anche se devi fare trucchi come distribuire le esecuzioni di test su macchine / CPU). Allo stesso modo, si può prestare attenzione per cercare di evitare metodi fragili di scrittura di test.

Voglio aggiungerne un'altra, un falso senso di sicurezza.

Oltre a insiemi di problemi ben definiti molto piccoli, non è possibile creare test completi. Nel nostro software potrebbero esserci e spesso ci saranno ancora errori che i test automatizzati semplicemente non testano. Quando passano i test automatici, troppo spesso si assume che non ci siano errori nel codice.

È difficile convincere il management / venture capitalist

• testautomation aumenta i costi iniziali.
• testautomation aumenta il time to market.
• il vantaggio di testautomation arriva nel mezzo e nel logterm. la feroce concorrenza si concentra maggiormente sui benefici a breve termine.

vedi Test delle unità market driven per i dettagli.

Uno dei principali svantaggi può essere superato utilizzando test di autoapprendimento. In questa situazione i risultati attesi sono tutti archiviati come dati e aggiornabili con una revisione minima da parte dell'utente della suite di test in modalità di autoapprendimento (mostra le differenze tra il vecchio risultato previsto e il nuovo risultato effettivo - aggiornamento previsto se si preme y). Questa modalità di apprendimento di testinguite deve essere utilizzata con cautela, in modo che il comportamento errato non sia appreso come accettabile.