Ultimamente ho sentito parlare molto dei test unitari.Quando/Come testare le applicazioni CRUD?
Quello che sto cercando di capire è come si dovrebbe/si dovrebbe andare su unità di test di un'app business cruddy? (fondamentalmente un'app che scrive dati in/legge dati da un database).
Il test di unità vale anche la pena in quello scenerio o di solito si esegue un test unitario di cose più complicate?
Grazie
test delle unità sta testando unità discrete di codice - un unico metodo, non di più.
Nel momento in cui si entra in CRUD, si sta parlando di test di rete, IO, database e altre cose - questo è al di là del test unitario. In questo caso, questo è chiamato test di integrazione (stai testando come il tuo codice si integra con altri codici/sistemi).
C'è posto per entrambi i tipi di test (e altri tipi - regressione, prestazioni ecc ...) in qualsiasi progetto software, applicazione CRUD o meno.
Il test unitario può testare diversi SUT (Sistema sotto test): due metodi o addirittura un gruppo di classi. La differenza tra i test unitari è molto confusa e non esiste una definizione chiara delle dimensioni e degli attributi di SUT di entrambi i test di unità o di integrazione. –
@Yauheni Sivukha - Da Wikipedia: un'unità è la più piccola parte testabile di un'applicazione. http://en.wikipedia.org/wiki/Unit_testing – Oded
@Odded - Wikipedia non dice che la più piccola parte testabile è il metodo. Dipende dal contesto. Se il test verifica i totali in ordine, deve riempire le righe dell'ordine. Ad ogni modo: http://stackoverflow.com/questions/10752/quello-è-la-differenza-tra-integrazione-eunitario-test-applicazioni –
Il test delle unità riguarda la verifica di PICCOLE bit di funzionalità semplici. Normalmente dovresti testare il livello dati della tua applicazione che gestirà tutte le funzionalità CRUD. Un test per creare e recuperare potrebbe essere simile a questo:
PrimaryKey = InsertObject(TestObject)
if PrimaryKey = 0 then
AssertTestFailed("Primary Key Not Returned.")
end if
NewInstanceOfObject = GetObject(PrimaryKey)
If NewInstanceOfObject <> TestObject then
AssertTestFailed("Record not located.")
else
AssertTestPassed("This Code is awesome UnitTest Passed.")
end if
Se tutti la vostra applicazione non fa altro che CRUD, allora non c'è alcun punto in unità di testarlo. Ora, se c'è qualche tipo di logica aziendale che manipola i valori quando escono dal db o li convalidano prima che entrino, sì, è una buona idea costruire test unitari. Il test della parte CRUD non appartiene al test unitario IMO.
Le app crudenti rimangono raramente crude. Alla fine crescono fino a includere un livello dell'oggetto business.
Quindi, sì, vorrei testare l'unità. Anche una semplice app di base dovrebbe essere suddivisa in un livello di interazione, un livello di accesso ai dati e un'interfaccia utente incredibilmente semplice (si noti che lo stato dell'interfaccia utente deve essere conservato nel livello di interazione). Alla fine, probabilmente otterrai un livello dell'oggetto business tra i livelli di interazione e accesso ai dati.
So che tutti vanno avanti e avanti su come si dovrebbe progettare prima tutto il test, ma io tendo ad attaccare con test unitari cose più complicate.
La mia regola empirica è che costruisco test automatizzati per cose che in realtà mi aspetto di rompere con regolarità, o cose che non noterò immediatamente sono infranti. E soprattutto, voglio che verifichi cose che non posso/non scriverò approfonditamente.
Ad esempio, il modulo "Calcola alcune cose complicate utilizzando 47 diverse variabili" dovrebbe avere una serie di test che ottengono una buona copertura del codice e coprono tutti i possibili percorsi di codice, ma il codice che salva in modo affidabile restituisce il risultato al database non ha necessariamente bisogno di un test, specialmente se si sta facendo un semplice lavoro CRUD.
Inoltre, mi piace utilizzare i test dell'interfaccia utente automatizzati (utilizzando WatiN o qualcosa di simile) per creare test di regressione per i miei siti, così quando cambio alcuni componenti principali posso eseguire un controllo di integrità per assicurarmi di non fai esplodere qualche angolo oscuro del sito.
Alla fine, è tutto sul ROI. Quanto tempo stai mettendo in questo, e quanto ne stai uscendo.Se i tuoi test unitari si avvicinano al 100% della copertura del codice su qualche livello di accesso ai dati stupido della tua app CRUDy business, stai sprecando il tuo tempo e il denaro del tuo datore di lavoro, in modo semplice e semplice. Ma se stai costruendo missili o dispositivi medici o se sei un negozio a due punti che non ha le risorse per un dipartimento di QA, molti test di unità possono farti risparmiare un sacco di tempo, denaro e/o vite .
test-first non riguarda il test dell'unità. Si tratta di una metodologia di progettazione chiamata TDD (o BDD per alcuni). – Oded
Test everything that could possibly break.
Ovviamente è necessario testare le operazioni CRUD soprattutto se si dispone di un'applicazione orientata ai dati. E dalla mia esperienza questo tipo di test sono test molto utili, perché possono catturare molti bug in mappature, logica di stored procedure, errori nel modello di dati, dati errati, ecc.
Quindi da quello che sto capendo da queste risposte I non dovrebbe leggere/scrivere il database del test unitario. Dovrei piuttosto testare codice di logica aziendale. – foreyez
Prova tutto ciò che potrebbe eventualmente rompersi. Questo è il senso comune. –