2009-06-03 20 views
8

Recentemente mi è venuta la domanda: vale la pena dedicare tempo allo sviluppo per generare test unitari automatici per progetti basati sul web? Voglio dire che a un certo punto sembra inutile perché a un certo punto quei progetti sono orientati alle interazioni con utenti/clienti, quindi non è possibile anticipare l'intera serie di azioni dell'utente in modo da essere in grado di verificare la correttezza dei contenuti mostrati. Anche il test di regressione può difficilmente essere fatto.
Quindi sono molto desideroso di sapere per conoscere l'opinione di altri sviluppatori esperti.Test automatici per progetti basati sul web

risposta

2

Non si può anticipare l'intero possibile insieme di azione da parte dell'utente in modo da essere in in grado di verificare la correttezza del indicato soddisfare.

Non è possibile prevedere tutti i dati possibili il codice sta per essere consegnato, o tutte le possibili condizioni di gara se è filettato, e tuttavia ancora fastidio unit testing. Perché? Perché puoi restringere il campo molto. Puoi anticipare il tipo di cose patologiche che accadranno. Devi solo pensarci un po 'e fare esperienza.

L'interazione dell'utente non è diversa. Ci sono alcune cose che gli utenti tenteranno di fare, patologiche o meno, e puoi anticiparle. Gli utenti stanno semplicemente inserendo dati particolarmente fantasiosi. Scoprirai che i programmatori tendono a perdere lo stesso tipo di condizioni ancora e ancora. Tengo una lista di controllo Ad esempio: pompare Unicode in tutto; inserire la data di inizio dopo la data di fine; inserire dati senza senso; metti tag in tutto; tralasciare il newline finale; prova ad inserire gli stessi dati due volte; inviare un modulo, tornare indietro e inviarlo di nuovo; prendi un file di testo, chiamalo foo.jpg e prova a caricarlo come immagine. Puoi anche scrivere un programma per capovolgere interruttori e pulsanti a caso, una scimmia cattiva, che troverà tutti i tipi di bug divertenti.

Spesso è semplice sedersi con qualcuno che non ha familiarità con il software e guardarlo mentre lo usa. Combatti l'impulso di correggerli, basta guardarli mentre si dimenano. È molto educativo. Steve Krug si riferisce a questo come "Advanced Common Sense" e ha un libro eccellente chiamato "Do not Make Me Think" che copre test di interazione utente semplice ed economico. Lo consiglio vivamente. È una lettura molto breve e ad occhi aperti.

Infine, il cliente stesso, se le sue aspettative sono adeguatamente preparate, può essere una fantastica suite di test. Assicurati che capiscano che è un work in progress, che avrà dei bug, che stanno aiutando a migliorare il loro prodotto, e che non dovrebbe assolutamente essere usato per i dati di produzione, e lasciare che si armino con le versioni pre-release di il tuo prodotto. Faranno ogni genere di cose a cui non hai mai pensato! Saranno i test migliori e più realistici che tu abbia mai avuto, GRATIS! Dare loro un modo molto semplice per segnalare bug, preferibilmente solo una casella di un pulsante proprio sull'applicazione che invia automaticamente il loro ambiente e la cronologia; la casella di feedback su Hiveminder è un esempio eccellente. Rispondere ai loro bug in modo rapido e educato (anche se è solo "grazie per le informazioni") e scoprirai che saranno lieti di essere così reattivi alle loro esigenze!

2

Sì, lo è. Ho appena avuto un problema questa settimana con un sito web su cui sto lavorando. Recentemente ho disattivato il livello di accesso ai dati e ho impostato i test delle unità per i miei controller e repository, ma non per le interazioni dell'interfaccia utente.

Sono stato morso da un bug piuttosto ovvio che sarebbe stato facilmente rilevato se avessi avuto test di integrazione. Solo attraverso test di integrazione e test di funzionalità dell'interfaccia utente si riscontrano problemi nel modo in cui i diversi livelli dell'applicazione interagiscono tra loro.

+0

I secondo questo. Non vedrai il valore finché non ti salverà il sedere. Allora ti chiederai come hai dormito la notte senza di essa. :) – cwash

+0

Ok, ma cosa intendi con test di integrazione? Come lo faresti? –

+0

Un test di integrazione verifica la funzionalità end-to-end. I test unitari normali testano solo la funzione/metodo che si desidera testare, nient'altro. Ad esempio, per testare unitamente un metodo nella propria logica aziendale che ottiene un elenco di clienti da un database, si eliminerebbe il database. Un test di integrazione, tuttavia, andrebbe fino in fondo al database e indietro, per verificare come tutto funziona insieme. La stessa cosa su una pagina web. Usando WATIN o selenio, puoi effettivamente colpire la pagina web che desideri testare e verificare che i dati vengano restituiti correttamente, ecc. Il test dovrebbe esercitare tutti i livelli del tuo codice. – Doanair

2

Se state scrivendo un sacco di Javascript, ci sono stati un sacco di framework di test JS che sono venuti intorno al blocco di recente per l'unità di testare il Javascript.

Oltre a ciò, testare il livello Web utilizzando qualcosa come Canoo, HtmlUnit, Selenium, ecc. È più un test funzionale o di integrazione rispetto a un test di unità. Questi possono essere difficili da mantenere se l'interfaccia utente cambia molto, ma possono davvero tornare utili. Registrare i test del selenio è facile e qualcosa che potresti probabilmente ottenere da altre persone (tester) per aiutarti a creare e mantenere. Sappi solo che esiste un costo associato al mantenimento dei test e che deve essere bilanciato.

Esistono altri tipi di test che sono eccezionali per il livello Web: il test fuzz in particolare, ma molte delle buone opzioni sono gli strumenti commerciali. Una che è open source e si collega a Rails si chiama Tarantula. Avere qualcosa del genere al livello web è un piacere aver funzionato in un processo di integrazione continua e non richiede molto sotto forma di manutenzione.

+0

Puoi consigliare il framework di test JS diverso da Firebug? –

+0

Dipende da cosa stai facendo Ora ci sono alcuni framework in stile BDD se stai inserendo un sacco di regole/caratteristiche in Javascript personalizzato. ScrewUnit è uno con cui ho giocato prima. FireUnit è integrato Firebug e funziona OK per i test generali. Non è fantastico per automatizzare o eseguire continuamente, howev ER. JSUnit è un buon uso generale. Se stai usando Prototype, controlla unittest.js da Script.aculo.us e se stai usando JQuery guarda in QUnit. – cwash

+0

C'è anche Test.Semplice. L'ho appena collegato con Selenium in modo che possa essere automatizzato e interpretato dalla riga di comando in modo che possano essere testati automaticamente. http://use.perl.org/~schwern/journal/39088 – Schwern

2

Dipende davvero dalla struttura e dall'architettura della tua applicazione web. Se contiene un livello logico dell'applicazione, allora quel livello dovrebbe essere facile da testare con strumenti di automazione come Visual Studio. Inoltre, l'utilizzo di un framework che è stato progettato per abilitare il test delle unità, come ASP.NET MVC, aiuta molto.

+0

Giusto, ma non sto parlando del livello della logica dell'applicazione. Ogni unità a livello di applicazione è facile da testare, ma l'integrazione sul client/browser è qualcosa di più complicato e sembra quasi inutile dedicare del tempo a coprire il 5-10% di tutte le possibilità.Sembra più comune sviluppare scenari utente e testare di conseguenza. –

1

I test unitari hanno senso nel processo TDD. Non hanno molto valore se non si fa lo sviluppo di test-first. Tuttavia i test di accettazione sono una grande cosa per la qualità del software. Direi che il test di accettazione è un santo graal dello sviluppo. I test di accettazione mostrano se l'applicazione soddisfa i requisiti. Come faccio a sapere quando smettere di sviluppare la funzione --- solo quando passano tutti i miei test di accettazione. L'automazione dei test di accettazione è una cosa importante perché non devo fare tutto manualmente ogni volta che apporto modifiche all'applicazione. Dopo mesi di sviluppo ci possono essere centinaia di test e diventa impossibile (a volte impossibile) eseguire tutto il test manualmente. Allora come faccio a sapere se la mia applicazione funziona ancora?

L'automazione dei test di accettazione può essere implementata con l'uso di framework di test xUnit, il che crea confusione qui. Se creo un test di accettazione usando phpUnit o httpUnit è un test unitario?La mia risposta è no. Non importa quale strumento io uso per creare ed eseguire test. Il test di accettazione è quello che mostra se le caratteristiche stanno lavorando ai requisiti IAW. Il test unitario mostra se una classe (o una funzione) soddisfa l'idea di implementazione dello sviluppatore. Il test unitario non ha valore per il cliente (utente). Il test di accettazione ha molto valore per il cliente (e quindi per lo sviluppatore, ricorda Customer Affinity)

Quindi I consiglia vivamente di creare test di accettazione automatici per l'applicazione Web.

I buoni quadri per il collaudo sono:

  • Sahi (sahi.co.in)
  • Silenium
  • SimpleTest (I't un quadro unit test php, ma comprende la oggetto browser che può essere utilizzato per il test di accettazione).

Tuttavia

lei ha detto che il web-site è tutto di interazione con l'utente, e quindi l'automazione di test non risolverà tutto il problema della fruibilità. Ad esempio: testing framework mostra che tutti i test passano, tuttavia l'utente non può vedere il modulo o il collegamento o altro elemento di pagina a causa di un errore accidentale style="display:none" nello div. I test automatici passano perché il documento div è presente nel framework e il framework di test può "vederlo". Ma l'utente non può. E il test manuale fallirebbe.

Pertanto, tutte le applicazioni Web richiedono test manuali. Il test automatizzato può ridurre drasticamente il carico di lavoro del test (80%), ma anche i test manuali sono significativi per la qualità del software risultante.

Per quanto riguarda il test dell'unità e TDD, rende la qualità del codice. È vantaggioso per gli sviluppatori e per il futuro del progetto (vale a dire per i progetti più lunghi di un paio di mesi). Tuttavia TDD richiede abilità. Se hai l'abilità, usala. Se non consideri di acquisire l'abilità, ma pensa al tempo che ci vorrà per guadagnare. Di solito ci vogliono circa 3 - 6 mesi per iniziare a creare buoni test e codici. Se il tuo progetto durerà più di un anno, ti suggerisco di studiare TDD e investire tempo in un ambiente di sviluppo adeguato.

+0

Non sono d'accordo con la dichiarazione sul test unitario nel processo TDD. Il test unitario ha sempre un senso per molte ragioni. –

0

Ho creato una soluzione di test Web (finestra mobile + cetriolo); è molto semplice e basilare, così facile da capire e modificare/migliorare. Si trova nella directory web;

la mia soluzione: https://github.com/gyulaweber/hosting_tests

+0

Purtroppo non ho abbastanza reputazione per incollare i riferimenti qui, quindi puoi vederli nel README github. – GyulaWeber

+0

Sebbene questo collegamento possa rispondere alla domanda, è meglio includere qui le parti essenziali della risposta e fornire il link per riferimento. Le risposte di solo collegamento possono diventare non valide se la pagina collegata cambia. –

+0

Hai ragione, ma è un codice di esempio, non so come condividerlo senza collegare github o altra pagina in cui il codice è raggiungibile. Penso che sia più facile iniziare con un esempio pronto da provare. Che cosa suggerisci, dovrei scrivere i punti chiave della soluzione e dare questo codice come esempio? – GyulaWeber

Problemi correlati