2010-07-24 18 views
13

Sto cercando un tutorial che spiega perché e come scrivere test di unità utili. Specificamente sono interessato a PHPUnit, tuttavia qualsiasi più generale potrebbe essere un buon modo per spiegarlo. Si prega di notare che non sto cercando informazioni tecniche su come utilizzare PHPunit - piuttosto il tutorial sul modo di pensare!Esercitazione su PHPUnit? O più generale - tutorial di test unitario che vale la pena di raccomandare?

+2

Sono stato a guardare questo thread per giorni, in quanto questo è un argomento in cui sono molto interessato. Triste per vedere la mancanza di risposte ... ci sono così tante opinioni diverse mi aspettavo un vera battaglia di ciambelle. Ad esempio, ho visto un ragazzo che stava facendo un discorso dicendo che odiava le canzonature - la sua sensazione generale era che la maggior parte delle volte si sentiva come se stessi testando la simulazione, non il codice. Dai! Discutere! – James

risposta

5

Non so di un tutorial. Ma posso darti le mie opinioni su ciò che ho raccolto nel corso degli anni.

Unità di scrittura I test hanno lo scopo di testare la funzionalità dell'applicazione. Detto questo, si scrive una classe principale che ha 3 funzioni, getData setData e displaydata (solo pensandoci sopra). Vuoi scrivere un caso unitario che va in set a Data (passi buoni dati e dati cattivi perché è importante sapere che si sbaglia correttamente). Quindi si controlla il setData, tramite una chiamata DB o con la stessa classe utilizzando getData, e si tenta di ottenere i dati con dati errati, dati buoni, ecc. Assicurarsi che questo sia gestito correttamente. Quindi scrivi i dati del display e risciacqui e ripeti.

In pratica si desidera verificare che la classe principale (o le classi di applicazione) gestiscano correttamente i dati (errori/dati validi ecc.). Se tutti i test risultano puliti, è possibile spostarsi e scrivere un test per altre classi che utilizzano quella classe principale. Ma non ha senso andare avanti se la tua classe principale non ha/non ha superato i test o altrimenti il ​​debug diventa una cavalla notturna. Non ho mai veramente esaminato il test dell'unità PHP, usavo solo scrivere tutti i miei scenari di caso d'uso (IE: come le funzioni sarebbero state utilizzate/implementate). Questo è un modo generale di pensare a cosa scrivere per un caso di prova.

Spero che questo aiuti.

2

Ho scritto una presentazione che copre proprio questo come un'introduzione. Speriamo che funzioni senza le note del relatore:
http://www.scribd.com/full/34941838?access_key=key-1u9c5kmupy1889f4o6tv (questo è in realtà ancora una revisione presto, tutte le risposte si poteva darmi sarebbe valutato :)

Si prende in prestito pesantemente dal libro "Patterns xUnit prova: Refactoring Codice di prova " http://rcm.amazon.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=alex010-20&o=1&p=8&l=as1&m=amazon&f=ifr&md=10FE9736YVPPT7A0FBG2&asins=0131495054"

anche guardare le presentazioni da parte Sebastian Bergmann il creatore di PHPUnit http://talks.php.net/index.php/Testing

Se potete permettervi il libro, sarebbe la mia raccomandazione numero uno per quanto riguarda l'apprendimento dei modelli di pensiero dei test unitari.

Infine (o forse come un pensiero dopo) i tuoi prossimi passi in alzarsi per 'standard professionali' nel QA trarrebbe beneficio passando attraverso la

Società Americana per la Qualità:http://www.asq.org/

Con il acquisto di un abbonamento (da circa $ 50 a $ 150 USD), è possibile iscriversi ai corsi e ottenere la certificazione in QA.

Inoltre, i materiali del corso di studio (costo sconosciuto) possono essere inviati al posto di lavoro per consentirvi di studiare autonomamente, scrivere un test, ottenere la certificazione e formare altri in QA.

Spero davvero che aiuti. - Alex

0

Il sito ufficiale del phpunit sta avendo buoni esempi e tutti i perché ei come.

Dai un'occhiata alla it

0

Sto solo cominciando a imparare a utilizzare correttamente e TDD Attualmente sto usando PHPUnit. Non posso esagerare abbastanza come il lavoro di Zio Bob (Robert C. Martin) mi ha aiutato. Sono abbastanza fortunato da avere una compagnia che ha offerto i video. Ma il suo lavoro con "Clean Code" è sorprendente.

Nei video utilizza un 'cap' per passare tra le diverse fasi di TDD (Rosso> Verde> Refactor) e descrive le fasi con dettagli eccellenti. Sto anche usando TDD Kata's per migliorare le mie abilità mentali di PHP e TDD. Credo che la mentalità non sia qualcosa a cui i programmatori sono abituati. Poiché si codifica per correggere un test non funzionante, si ritiene che piccolo piuttosto che grande. Segregare l'attività specifica che stai facendo al codice ti impedisce di allontanarti troppo. In un dato momento si sta codificando per passare un test, superare un test o refactoring del codice, mai in mezzo. E poiché si tratta di piccole iterazioni, credo che sia meglio con lo sviluppatore - lo fa con me!

Devo sottolineare che sono uno sviluppatore dilettante e ho appena iniziato (anzi questo è il mio primo post!). Secondo me il primo approccio del test funziona davvero bene. Ti costringe a scrivere codice modulare, perché deve testare. Tu, a tua volta, scrivi un codice che rispetta i principi SOLID.

Vacci piano con me. Sto ancora imparando :)