Quali sono gli svantaggi dei test automatizzati?

Ci sono una serie di domande su questo sito che forniscono molte informazioni sui vantaggi che possono essere ottenuti dai test automatizzati. Ma non ho visto nulla che rappresentasse l'altro lato della medaglia: quali sono gli svantaggi? Tutto nella vita è un compromesso e non ci sono proiettili d'argento, quindi sicuramente ci devono essere alcuni motivi validi per non fare test automatizzati. Quali sono?

Eccone alcuni che ho escogitato:

• Richiede più tempo iniziale per gli sviluppatori per una determinata funzionalità
• Richiede un livello di abilità superiore dei membri del team
• Aumentare le esigenze degli utensili (test runner, framework, ecc.)
• Analisi complesse richieste quando si verifica un test fallito: questo test è obsoleto a causa della mia modifica o mi sta dicendo che ho fatto un errore?

Modifica
Dovrei dire che sono un grande sostenitore dei test automatizzati e non sto cercando di essere convinto di farlo. Sto cercando di capire quali sono gli svantaggi, quindi quando vado nella mia azienda a presentare una richiesta per questo non mi sembra di lanciare il prossimo proiettile d'argento immaginario.

Inoltre, sono esplicitamente non alla ricerca di qualcuno che disponga i miei esempi sopra. Sto assumendo la verità che ci devono essere alcuni svantaggi (tutto ha dei compromessi) e voglio capire quali siano.

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 ancora necessari test di integrazione e di sistema, che potrebbero richiedere anche un codice di automazione. Il codice scritto una volta viene solitamente testato in diverse fasi successive.

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

• Esigenze degli utensili: sei lì. Non c'è molto da aggiungere a questo.

• Test falliti: questo è il vero problema (per me comunque). Esistono diverse ragioni, ognuna delle quali può essere vista come uno svantaggio. E il più grande svantaggio è il tempo necessario per decidere quale di questi motivi si applica effettivamente al test fallito.

  • fallito, a causa di un bug reale. (solo per completezza, poiché questo è ovviamente vantaggioso)
  • non riuscito, perché il codice di test è stato scritto con un bug tradizionale.
  • non riuscito, perché il codice di test è stato scritto per una versione precedente del prodotto e non è più compatibile
  • non riuscito, poiché i requisiti sono cambiati 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 ti avvicini alle risposte di Adamo. Se cambi qualcosa nel codice del tuo prodotto, ma il test non lo tiene affatto conto, ti dà questo "falso senso di sicurezza".

  Un aspetto importante dei test non falliti è che una modifica dei requisiti può rendere non valido il comportamento precedente. Se hai una tracciabilità decente, la modifica dei requisiti dovrebbe poter essere abbinata al tuo codice di test e sai che non puoi più fidarti di quel test. Naturalmente, mantenere questa tracciabilità è un altro svantaggio. E se non lo fai, si finisce con un test che non fallisce, ma in realtà verifica che il tuo prodotto funzioni in modo errato . Da qualche parte lungo la strada questo ti colpirà .. di solito quando / dove meno te lo aspetti.

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

Avendo appena iniziato a provare i test automatici nel nostro team, il più grande svantaggio che ho visto è che è molto difficile applicare al codice legacy che non è stato progettato pensando ai test automatici. Indubbiamente migliorerebbe il nostro codice a lungo termine, ma il livello di refactoring necessario per i test automatizzati pur mantenendo la nostra sanità mentale è una barriera molto elevata per l'ingresso a breve termine, il che significa che dovremo essere molto selettivi sull'introduzione automatizzata unit test per soddisfare i nostri impegni a breve termine. In altre parole, è molto più difficile pagare le carte di credito quando si è già profondamente indebitati.

Forse lo svantaggio più importante è ... i test sono il codice di produzione . Ogni test che scrivi aggiunge codice al tuo codebase che deve essere mantenuto e supportato. Non farlo porta a test di cui non credi ai risultati, quindi non hai altra scelta. Non fraintendetemi, sono un grande sostenitore dei test automatizzati. Ma tutto ha un costo, e questo è grande.

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

• Tempo impiegato per impostare il test in un'applicazione enterprise complessa.
• Gestire vecchi test che falliscono in modo errato, in altre parole, il sistema si è evoluto e ora i test sono sbagliati.
• Falsa fiducia dalla copertura del test irregolare o sconosciuta.

La copertura dei test irregolare può portare a un falso senso di sicurezza. Se fai un refattore 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 anche test di casi. Questi tendono ad essere più ampi e richiedono un contesto.

Certo, la mia prospettiva proviene da un'applicazione che è 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 stiano effettivamente facendo qualcosa e che include test adeguati dei requisiti.

Inoltre, i test automatici possono anche includere bug stessi , in modo da porre la questione se i test unitari debbano essere testati in modo da non ottenere necessariamente nulla.

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

• È richiesta competenza per scrivere gli script dei test di automazione.
• Il debug dello script di test è un grosso problema. Se è presente un errore nello script di test, a volte può portare a conseguenze mortali.
• La manutenzione del test è costosa in caso di metodi di riproduzione. Anche se si verifica una piccola modifica nella GUI, lo script di test deve essere registrato nuovamente 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 il vantaggio ottenuto dagli script automatizzati. Sebbene i test di automazione abbiano vantaggi e vantaggi, è ampiamente adattato in tutto il mondo.

Di recente ho fatto una domanda sui test nello sviluppo del gioco : ecco come lo sapevo. Le risposte hanno indicato alcuni svantaggi curiosi e specifici:

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

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

• I test automatici possono farti sentire che il QA e i test non sono importanti.

Inoltre, stavo pensando in quei giorni alla documentazione e ho cogitato un'ipotesi che potrebbe essere valida (in misura minore) per i test due. Ho appena sentito che il codice si evolve così rapidamente che è abbastanza difficile creare una documentazione che segue una tale velocità, quindi è più prezioso dedicare tempo a rendere il codice leggibile piuttosto che scrivere documentazione pesante e facilmente obsoleta. (Ovviamente, 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 rileggi molto, molto attentamente .

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

Ho altre esperienze sugli svantaggi dei test automatizzati, ma la maggior parte di essi sono elencati in altre risposte. Tuttavia, sono un sostenitore veemente dei test automatizzati. Ciò ha risparmiato moltissimo lavoro e mal di testa e lo consiglio sempre di default. Ritengo che tali svantaggi siano solo semplici dettagli rispetto ai vantaggi dei test automatizzati. (È importante proclamare sempre la tua fede dopo aver commentato le eresie per evitare l'auto da fé.)

Due che non sono menzionati sono:

• Durata del tempo impiegato per eseguire una suite di test di grandi dimensioni

Ho preso parte agli sforzi di controllo qualità automatizzati in cui ci sono voluti mezza giornata per eseguire i test, perché i test erano lenti. Se non stai attento con la scrittura dei test, anche la tua suite di test potrebbe risultare in questo modo. Questo non suona come un grosso problema fino a quando ora non riesci a gestire "Oh, ho appena commesso una correzione, ma ci vorranno 4 ore per dimostrare la correttezza".

• Fragilità di alcuni metodi di scrittura di prova

Alcuni metodi di test (come l'automazione dell'interfaccia utente) sembrano rompersi ogni volta che ci si gira. Particolarmente doloroso se il tuo script, per esempio, blocca il processo di test perché è in attesa che appaia un pulsante, ma il pulsante è stato rinominato.

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

Voglio aggiungerne un altro, un falso senso di sicurezza.

Al di là di insiemi di problemi ben definiti molto piccoli, non è possibile creare test completi. Ci possono essere e spesso ci saranno ancora bug nel nostro software per i quali i test automatizzati semplicemente non testano. Quando i test automatici vengono superati, tutti troppo spesso assumiamo che non ci siano bug nel codice.

È difficile convincere il management / venture capitalist

• la testautomation aumenta i costi iniziali.
• la testautomation aumenta il time to market.
• il beneficio della testautomazione arriva nel mezzo e nel logterm. la forte concorrenza si concentra maggiormente sui vantaggi a breve termine.

vedere Test di unità guidati dal mercato 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à autoapprendimento (mostra le differenze tra il vecchio risultato atteso e il nuovo risultato effettivo - aggiornamento previsto se si preme y). Questa modalità di apprendimento della suite di test deve essere utilizzata con cautela, pertanto il comportamento errato non viene appreso come accettabile.