Come posso citare un lavoro con PHPUnit?

Ho programmato siti Web per 15 anni e PHP negli ultimi 5 anni circa. Ho sempre scritto codice solido. TUTTAVIA, ho un client che insiste sull'80% del codice testato dall'unità. Poiché il client è SEMPRE GIUSTO, sto programmando di utilizzare PHP_CodeSniffer per assicurarmi che il mio codice sia corretto e PHPUnit per eseguire il test dell'unità. Spero di imparare qualcosa attraverso questa esperienza.

Questi sono gli strumenti giusti da usare? Quanto tempo è necessario per impostare PHPUnit e scrivere il codice aggiuntivo? Dovrei impiegare circa 8 settimane per scrivere le pagine Web e l'autotest come ho fatto in passato. Se aggiungo altri 4 giorni (10%) per i test unitari (PHPUnit), è sufficiente? Pensieri? Suggerimenti? Grazie.

In una riga: dipende da come lavori. Credo fermamente che il 10% sia troppo poco. Dovrebbe essere almeno del 25%, se non del 40%, se non del 60%, se non di più.

Innanzitutto, sono molto d'accordo con il tuo cliente lì. I test unitari sono una parte essenziale di un prodotto robusto, di facile manutenzione e di debug.

Parlerò da quello che so. Uso TDD (Test-Driven Development) per la maggior parte dei progetti. TDD fondamentalmente ti fa scrivere i test prima del codice reale. Stabiliscono una serie di criteri di accettazione che il prodotto finale deve soddisfare. Di solito, passerai dal 50% al 70% del tuo tempo a scrivere test e il resto a implementare il codice per farli passare.

Anche se può sembrare assurdo e / o enorme, posso assicurarti che non lo è. Ecco perché:

• Sarai in grado di capire quali sono i migliori modelli architettonici da utilizzare durante la scrittura dei test. In questo modo, quando inizi a scrivere codice, l'architettura dell'applicazione cambierà minimamente (perché sappiamo tutti quanto sia costoso ripetere un'architettura applicazione).
• Si codifica solo per superare i test (rendendo quindi accettabile il prodotto finale). Non perderai tempo a programmare funzioni inutili / fuori campo.
• Avendo meno codice (ovvero: solo codice di cui hai effettivamente bisogno), è meno soggetto a errori. (Meno codice = meno errori).
• Se commetti un errore, e lo farai, ci vorrà molto meno tempo per capire perché c'è un problema e dove si trova il problema. Se i test sono scritti correttamente, significa che un singolo errore provocherà un singolo fallimento, non una reazione a catena. In questo modo è possibile individuare facilmente l'origine del problema in pochi minuti, se non in pochi secondi.
• Ci vorrà molto meno tempo per implementare il codice effettivo con unit test. Non appena un test fallisce, sai che qualcosa non va. Non devi fare avanti e indietro con il client per correggere i bug.
• Alla fine dovrai fare avanti e indietro con il client per correggere i bug, perché nulla può rilevare il 100% degli errori. Tuttavia, puoi facilmente catturare il 95% se non di più.

PHPUnit è praticamente lo strumento di fatto per test unitari PHP, ed è molto bravo in questo. Non ho usato molto PHP_CodeSniffer. Tuttavia, penso che se lavori da solo, probabilmente non ti serve. È più utile in un team assicurarsi che il codice abbia lo stesso aspetto, indipendentemente da chi lo ha codificato.

Ti consiglio di avere l'atteggiamento che imparerai qualcosa da questa esperienza. Sono sicuro che lo farai.

La prima cosa che dovresti imparare è che la necessità di test unitari non ha nulla a che vedere con la tua esperienza . Il miglior sviluppatore sarà anche uno dei migliori tester di unità:

Bill Venners: Nel tuo libro dici Rifattorizzare: "Se vuoi refactoring, il presupposto essenziale è avere test solidi". Vuol dire che se non hai dei test non dovresti fare il refactoring?

Martin Fowler: dovresti pensarlo come camminare sul filo del rasoio senza rete. Se sei bravo a camminare sul filo del rasoio e non è così in alto, allora potresti provarlo. Ma se non hai mai camminato su una corda tesa prima, ed è sopra le Cascate del Niagara, probabilmente vorrai una buona rete.

^{Da http://www.artima.com/intv/refactorP.html}

Scrivevo PHP senza test unitari. Quindi, dopo anni di pratica di unit test in Java, ho scoperto che non avrei potuto lavorare su qualcosa di molto più complicato delle singole pagine in PHP senza unit test. La ragione? Produttività . Senza test unitari, non potrei rifattorizzare con sicurezza - questo significa che o A) dovrei abbattere molto di più e lavorare di nuovo su tutto dall'inizio, oppure B) , dovrei affrontare un brutto codice legacy.

Quando fai un'offerta devi considerare il tempo necessario per testare? Sì . Ti sembra intuitivo che ci vorrà più tempo? Sì, ancora una volta . Probabilmente, come altre stime hanno approssimativamente stimato, sarà necessario stimare il 50-100% in più rispetto a senza test unitari.

Però!...

• Prenderete e risolverete i buchi delle specifiche in precedenza
• Ciò significa che svilupperai una specifica più pulita e più solida
• Sarai in grado di rispondere rapidamente e con sicurezza alle modifiche alle specifiche
• Avrai meno bug
• I tuoi bug verranno catturati prima e più facilmente risolvibili

Di conseguenza, le tue stime saranno più accurate . Se addebiti ogni ora, stupirai di più i tuoi clienti e sarai in grado di aumentare le tue tariffe. Se addebiti un importo forfettario, guadagnerai più denaro all'ora.

Senza test, le tue stime sono molto probabilmente un crapshoot. Bug, ordini di cambiamento e ridefinizioni sono tutti terribili per la stima accurata. I test sono la chiave per ridurre al minimo l'impatto di tutti e tre!

Non c'è una risposta facile per quanto tempo ci vorrà.

Ma come regola di base, se si tratta di un progetto breve: direi che lo sviluppo insieme a buoni test unitari richiederà 1,75-2 volte di più dello sviluppo senza test unitari. Per progetti più lunghi forse il 25-30%?

Suggerisco di effettuare test unitari prima di scrivere il codice. Preso in questo modo, la costruzione del ponteggio unit test diventa effettivamente parte del processo di progettazione e quindi non dovresti considerare che stai perdendo tempo a test unitari, ma piuttosto che la costruzione del test unitario ti sta aiutando a progettare un ottimo prodotto e l'esistenza di quel test dopo averlo creato ti rende più facile assicurarti che rimanga tale. Dover scrivere i primi test unitari è meraviglioso nell'aiutarci a concentrarci su requisiti reali, ci fornisce un modo chiaro per verificare se abbiamo finito (superando i test unitari) e ci aiuta a "testare presto e testare spesso".

Per quanto riguarda PHPUnit .... È da un po 'che non lo uso, la mia impressione è che sia potente ma forse ha bisogno di più lavoro prima che sia davvero lucido.

Se c'è una cosa che voglio comunicare qui, però: per favore, non vedere Unit Testing come una semplice formalità alla fine del tuo progetto. Se è tutto ciò che è, secondo me, è inutile.

Le risposte finora sono abbastanza approfondite, quindi aggiungerò solo un punto non coperto: sarà il tempo extra dovuto all'uso di PHPUnit

1. all'inizio più in alto da quando lo stai imparando, e
2. abbassa i tempi di sviluppo non di prova man mano che acquisisci sicurezza.

Le classi del modello di unit test che non trattano la presentazione sono piuttosto semplici. Scrivi un test per ogni classe e in quei casi puoi creare un'istanza e configurare direttamente un oggetto per testare un particolare metodo / funzionalità. Dopo aver configurato e avviato PHPUnit, sarai in grado di far funzionare rapidamente questi test.

Le pagine Web di unit test possono essere più complicate. Se usi Zend Framework, Symfony, Smarty o qualsiasi altro motore MVC, ottenere PHPUnit per giocare bene con loro può richiedere più tempo. Usiamo Zend Framework e ho trascorso molto tempo a costruire classi di base per testare i controller e visualizzare gli script in modo isolato. Date le dimensioni di questo progetto, probabilmente è meglio iniziare ControllerTestCase.