Domanda

Buongiorno,

Sto lavorando con un gruppo di sviluppatori offshore che hanno usato il termine test unitario piuttosto vagamente.

Il loro documento di QA parla della scrittura di unit test e quindi dell'esecuzione di unit test del sistema.

Questo non è in linea con la mia interpretazione di cosa sia il test unitario.

Sono abituato a test di unità come test o suite di test che vengono utilizzati per esercitare una singola classe, generalmente come una scatola nera. La classe in prova può richiedere che altre classi siano incluse dall'implementazione, ma generalmente è una singola classe che viene esercitata dai test di unità.

Quindi hai test funzionali di sistema, test di integrazione, test di accettazione, ecc.

Voglio sapere che è un po 'pedante da parte mia? O è questo ciò che pensi quando ti riferisci ai test unitari e ai test unitari?

Modifica: Rob Wells. Devo chiarire che l'approccio a tali test da una prospettiva black box è solo un aspetto. Quando usi oggetti finti per verificare comportamenti interni, stai davvero testando dal punto di vista della scatola bianca perché sai cosa vuoi che accada all'interno della scatola.

È stato utile?

Soluzione

Cerco di implementare unit test per testare un solo metodo. e faccio uno sforzo per cretare "deridere" classi per classi dipendenti e metodi usati dal metodo che sto testando ... ... in modo che l'esercizio del codice in quel metodo in realtà non chiami il codice in altri metodi il test unitario non dovrebbe essere "Testing" (Esistono altri test unitari per questi metodi) In questo modo, un fallimento del test unitario indica in modo affidabile un fallimento del metodo che il test unitario sta testando ...

Le classi simulate sono progettate per "simulare" l'interfaccia e il comportamento delle classi dipendenti in modo che il metodo che sto testando possa chiamarle e si comporteranno in un modo standard e ben definito in base ai requisiti di sistema. Per far funzionare questo approccio, le chiamate a tali classi dipendenti e ai loro metodi devono essere effettuate su un'interfaccia ben definita, in modo che il "tester" il processo può " iniettare " la versione Mock della classe dipendente nella classe in fase di test invece della versione di produzione effettiva .... Questo è un po 'come un modello di progettazione comune indicato come "Iniezione di dipendenza", o "Inversione del controllo" (IOC)

Esistono diversi strumenti di terze parti sul mercato per aiutarti a implementare questo tipo di modello. Uno di cui ho sentito parlare si chiama "Rhino-Mock" o qualcosa del genere ...

Modifica: Rob Wells. @Charles. Grazie per questo. Avevo dimenticato di usare oggetti simulati per sostituirli completamente usando altre classi tranne quella sotto test.

Un paio di altre cose che ho ricordato dopo aver menzionato oggetti finti è che:

  • possono essere utilizzati per simulare errori restituiti dalle classi incluse.
  • possono essere utilizzati per generare eccezioni specifiche per verificare la gestione delle eccezioni nella classe sottoposta a test.
  • possono essere utilizzati per simulare articoli in cui i costi di installazione sono elevati, ad es. un grande back-end di SQL DB.
  • possono essere utilizzati per verificare il contenuto di una richiesta in arrivo.

Per ulteriori informazioni, dai un'occhiata al documento di Martin Fowler intitolato " Mock Aren't Stubs " e l'articolo di The Pragmatic Programmers " Mock Objects "

Altri suggerimenti

I test unitari sono generalmente utilizzati dagli sviluppatori per testare sezioni di codice isolate. Coprono casi limite, casi di errore e casi normali. Hanno lo scopo di dimostrare la correttezza di un segmento limitato di codice. Se tutti i test unitari superano, allora hai dimostrato che i tuoi segmenti di codice isolati fanno quello che dovrebbero fare.

Quando esegui il test di integrazione, stai esaminando i casi end-to-end, per vedere se tutti i segmenti che hanno superato il test unitario funzionano insieme. Il test funzionale verifica se il codice soddisfa i requisiti specificati. Il test di accettazione viene eseguito dagli utenti finali per verificare se approvano il prodotto finale.

Non vi è alcun motivo per cui i test unitari non possano estendersi su più classi o anche sottomoduli, purché il test stia trattando solo un'operazione commerciale coerente. Pensa a "calcolareWage", un metodo di BO che utilizza strategie diverse per calcolare lo stipendio di una persona. Questa è una unit test secondo me.

Ho sentito parlare di tecniche in cui molti dei test unitari vengono eseguiti per primi e lo sviluppo avviene attorno a loro. Qualcuno ha appena commentato dicendo che questo è "Test Driven Development" - TDD (Grazie Elie).

Ma se si tratta di un'operazione offshore che probabilmente ti farà pagare più soldi perché passano il tempo a fare questi test unitari, allora starei attento. Ricevi una seconda opinione da qualcuno, esperto di unit test che verificherà che stiano effettivamente facendo come si suol dire.

Per quanto ne so, i test unitari aggiungeranno un po 'più di tempo a qualsiasi progetto di sviluppo, ma ovviamente potrebbero offrire un controllo di qualità. Tuttavia, questo è il tipo di controllo di qualità che vorrei con un progetto interno. Questo potrebbe essere solo qualcosa che la società offshore lancia là fuori per darti un caldo sfocato.

Esiste una differenza tra il processo utilizzato per il test e la tecnologia utilizzata per supportarlo. I vari framework utilizzati per i test unitari sono generalmente molto flessibili e possono essere utilizzati per testare piccole unità di codice, unità di grandi dimensioni e persino testare interi processi. Questa flessibilità può creare confusione.

La mia raccomandazione è che qualunque metodologia o processo specifico tu adotti, devi separare i vari Unit Test in assiemi o moduli distinti. La disposizione esatta dipende dal codice e dall'organizzazione della tua azienda.

L'effetto cumulativo dell'utilizzo del framework Unit Test è che gran parte del testing del codice è automatizzato. Gli sviluppatori adottati correttamente possono valutare meglio le modifiche al codice senza passare attraverso un processo completo di domande e risposte. Per quanto riguarda il Q & amp; Un processo in sé rende il loro tempo più produttivo poiché la qualità del codice che esce dallo sviluppo dovrebbe essere più elevata.

Comprendi che non è LA risposta a tutti i problemi di qualità, ma solo uno strumento utile come l'altro che usi.

Wikipedia sembrerebbe suggerire che il test unitario consiste nel testare la più piccola quantità di codice che sarebbe un metodo su una classe nel caso della programmazione OO.

Alcuni potrebbero avere un termine più generale di ciò che intendono per test unitari, mentre alcuni potrebbero pensare che alcuni test di integrazione siano test unitari in cui l'unità è una miscela di componenti.

esiste una visione tradizionale di http://en.wikipedia.org/wiki/Software_testing come parte di http://en.wikipedia.org/wiki/Software_engineering . ma mi piace l'idea di un unit test agile: un test è un unit test agile se è abbastanza veloce in modo che i programmatori sempre lo eseguano.

Un test unitario è la più piccola e unica parte di fiducia che puoi ottenere sulla strada giusta per essere fatto. Questo è ciò che conta, costruendo iterativamente uno scudo contro la regressione e la deviazione delle specifiche, non il modo in cui lo integri effettivamente nella tua architettura orientata agli oggetti.

Questa è quasi una ripetizione di " Che cos'è un '"unità"? " ; domanda.

" Unità " può essere definito in modo flessibile. Se il loro documento non ha una definizione di "unità", è necessario chiarirlo.

Potrebbe essere che pensano all'unità come a un grande insieme di codice. Quale non è la definizione più desiderabile.

Mentre sono d'accordo che hai diversi livelli di test (unità, modulo, pacchetto, applicazione), penso anche che gran parte di questo può essere fatto con strumenti di test unitari. Portando a "cos'è un'unità" " domande che sorgono continuamente.

L'unità dipende dal contesto. Per un singolo sviluppatore, l'unità deve essere Classe. A volte, significherà anche modulo o pacchetto.

Per una squadra, tuttavia, la sua unità può essere un pacchetto o un'applicazione completa.

Cosa importa cosa pensiamo? Il problema qui è la tua infelicità per i termini che usano nel documento. Perché non ne parli con loro?

Dieci anni fa, prima dell'uso corrente di " unit testing " come test scritti in codice, la stessa designazione è stata applicata ai test manuali. Ho lavorato per una società di sviluppo software con un processo di sviluppo software molto formalizzato. Abbiamo dovuto scrivere "unit test" prima di scrivere qualsiasi codice. In quell'epoca, i test unitari erano scritti in un documento di testo (come in Word). Descrivevano i passaggi esatti che l'utente doveva seguire per utilizzare l'app. Ad esempio, hanno descritto l'input esatto da digitare nella pagina per impostare un nuovo cliente. In alternativa, l'utente doveva cercare un determinato prodotto e verificare che le informazioni visualizzate corrispondessero al documento di prova. Quindi, il test era una sceneggiatura seguita dal tester, dove registravano anche i risultati. Quando è arrivata la nuova incarnazione dei test unitari, è stato per un po 'confuso cercare di capire se intendessero i vecchi test umani o i nuovi test codificati.

Dirigo anche un gruppo di team offshore. Supponiamo di avere una serie di test unitari ... ma non significa molto. :) Quindi contiamo molto di più sul funzionale e sui tester per la qualità. Il problema intrinseco con i test unitari è che hai una perfetta conoscenza dei funzionali e che ti fidi degli sviluppatori. Nel mondo reale, è difficile supporre ..

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top