Introduzione ai test [chiuso]

Ecco alcuni suggerimenti per iniziare almeno. Tutto qui elencato è gratuito.

• un framework webtest, che "fa clic" attraverso il browser / webapp - Selenium

• un framework extjs / javascript unittest - Jasmine o Mocha

• un C # unittest framework - NUnit

• forse un framework che verifica se le chiamate web forniscono valori di ritorno corretti e come le chiamate web reagiscono a "garbage in"? - NUnit , implementato come test che chiama i servizi Web e verifica le risposte previste

• forse anche un framework sql unittest per stored procedure - NUnit , implementato come test che chiama i processi memorizzati e la verifica dei risultati attesi (dall'output del processo memorizzato o con le query di follow-up per confermare le modifiche previste dei dati)

A proposito, ho lavorato in una società che non conosceva praticamente i test automatici / programmatici (i test sono stati eseguiti manualmente o non lo sono affatto). Ma ho gettato insieme un test di regressione UI automatizzato usando il selenio, e li ha spazzati via. A volte le persone hanno solo bisogno di una buona dimostrazione.

Questo è tutto generale, non specifico per le tue esigenze.

Cose casuali che ho imparato dal processo di aggiunta di unit test al mio progetto C ++ (non tutto da esperienza personale):

I test di integrazione
• non sono come i test unitari. Ci sono molti cablaggi che supportano solo i test unitari, non i test di integrazione. Lo stesso script che chiama il tuo harness di test dovrebbe anche eseguire un formattatore di codice ed eseguire un errore se fa una diff.
• Un make test correttamente scritto sarà in grado di eseguire nuovamente i test solo se il codice pertinente è stato modificato. Suggerimento: ogni test binario genera un file di log (più utile di un file di timbro).
• un buon framework di test supporta l'isolamento a livello di processo e divide la responsabilità di scegliere i test e registrare i loro risultati dal loro effettivo funzionamento. TAP , che ha avuto origine da perl, è un buon esempio di come farlo ed è utilizzabile per qualsiasi lingua.
• Usa un servizio CI maleducato con una matrice. Ciò è utile anche senza alcuna suite di test, per rilevare errori del compilatore che si verificano solo con una versione del compilatore.
• Se la tua matrice è troppo grande, o se il tuo robot CI sta impiegando troppo tempo per una singola matrice, forse hai troppe librerie in bundle. Anche se è una libreria specificamente scritta per questo progetto, se è isolata abbastanza da essere un repository separato con le sue proprie build CI (che generano indirettamente i binari da utilizzare nelle build CI del progetto principale), dovrebbe essere. Se non è abbastanza isolato, fallo così.
• è impossibile eseguire un test unitario in presenza di variabili globali. Uccidili con il fuoco. Se ucciderli è troppo difficile, in least isolarli in un singolo oggetto Globals globals per libreria / binario. Ma le librerie non dovrebbero mai esporre un'API che si basa comunque su globalmente.
• realisticamente, non aggiungerai test a tutto il tuo vecchio codice. Piuttosto, aggiungi dei test sia quando scrivi un nuovo codice che quando arrivano segnalazioni di bug.
• quando scrivi un nuovo codice, scrivi velocemente del codice per farti un'idea di ciò di cui hai veramente bisogno, poi cancella tutto e scrivi i test unitari, quindi costruisci un'implementazione secondo necessità per superare i test unitari. Questo finisce per essere molto più semplice.
• i tuoi test possono e si basano su ipotesi implicite sulla classe / funzione che stanno testando, ma la classe / funzione testata sarà modificata da un idiota un giorno (probabilmente tu).

Il mio consiglio generale è: non non legarti a una particolare tecnologia. Hai esigenze speciali, scrivi un piccolo codice che funziona con il tuo codice invece di girare per adattarlo a un framework. TAP è particolarmente indicato per permetterti di scrivere la tua colla anziché costringerti a usare lego e persino a chiamare altre imbracature di test.