Come cito un lavoro con PHPUnit?

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

In primo luogo, sono molto d'accordo con il tuo cliente lì. I test unitari sono una parte essenziale di un prodotto robusto, facile da mantenere e facile da debugare.

Parlerò di ciò che so. Io uso TDD (Test-Driven Development) per la maggior parte dei progetti. Fondamentalmente TDD ti fa scrivere i test prima del codice reale. Stabiliscono una serie di criteri di accettazione che il prodotto finale deve soddisfare. Solitamente, trascorrerai 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 schemi architettonici da utilizzare durante la scrittura dei test. In questo modo, quando inizi la codifica, l'architettura dell'applicazione cambierà in minima parte (perché sappiamo tutti quanto sia costoso rifare l'architettura di un'applicazione).
• Codice solo per superare i test (rendendo quindi accettabile il prodotto finale). Non passerai il tempo a programmare funzioni inutili / fuori portata.
• Avendo meno codice (vale a dire solo il codice che è effettivamente necessario), è 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 causerà un singolo errore, non una reazione a catena. In questo modo puoi facilmente individuare la fonte del problema in pochi minuti, se non secondi.
• Ci vorrà molto meno tempo per implementare il codice reale con i test unitari. 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ò catturare il 100% degli errori. Tuttavia, puoi facilmente ottenere il 95% se non di più.

PHPUnit è praticamente lo strumento de facto per testare le unità PHP, ed è molto buono in questo. Non ho usato molto PHP_CodeSniffer. Tuttavia, penso che se stai lavorando da solo, probabilmente non ne hai bisogno. In una squadra è più utile assicurarsi che il codice sia lo stesso, indipendentemente da chi lo abbia codificato.

Puntelli per te per avere l'attitudine che imparerai qualcosa da questa esperienza. Sono sicuro che lo farai.

La prima cosa che dovresti imparare è che la necessità di test delle unità non ha nulla a che fare con quanto sei esperto . Il miglior sviluppatore sarà anche uno dei migliori tester per unità:

Bill Venners: You say in your book Refactoring: "If you want to refactor, the essential precondition is having solid tests." Does that mean if you don't have tests you shouldn't refactor?

Martin Fowler: You should think of it as walking a tightrope without a net. If you are good at walking a tightrope, and it's not that high up, then you might try it. But if you've never walked a tightrope before, and it's over Niagara Falls, you probably want a good net.

^{Da link}

Scrivevo PHP senza test di unità. Poi, dopo anni di pratica dei test unitari in Java, ho scoperto che non potevo lavorare su qualcosa di molto più complicato delle singole pagine in PHP senza test delle unità. La ragione? Produttività . Senza test di unità, non potevo refactoring con fiducia - questo significava che A) avrei dovuto strappare molto di più e lavorare su tutto dall'inizio ancora, o B) , Dovrei avere a che fare con un brutto codice legacy.

Quando fai un'offerta, devi calcolare il tempo necessario? Sì . Sembra intuitivo che impiegherà più tempo? Sì, di nuovo . Probabilmente, come alcune altre risposte hanno stimato approssimativamente, è necessario stimare 50-100% più grande di senza test unitari.

Tuttavia! ...

• Catturerai e indirizzerai i fori delle specifiche in precedenza
• Il che significa che svilupperai una specifica più pulita e 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 da correggere

Come risultato, 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 una stima accurata. Il test è la chiave per ridurre al minimo l'impatto di tutti e tre!

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

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

Suggerisco di fare test di unità prima di scrivere il tuo codice. In questo modo, la costruzione del ponteggio dell'unità di prova diventa effettivamente parte del processo di progettazione e quindi non si deve considerare che si sta perdendo tempo per i test unitari, ma piuttosto che la costruzione del test unitario ti aiuta a progettare un ottimo prodotto e l'esistenza di quel test dopo averlo creato ti rende più facile per te assicurarti che rimanga tale. Dover scrivere dei primi test di unità è meraviglioso per aiutare a concentrarci sui requisiti reali, ci fornisce un modo chiaro per verificare se abbiamo finito (superando i test unitari) e ci aiuta a "testare precocemente e testare spesso".

Come per PHPUnit .... È passato un po 'di tempo da quando l'ho usato, la mia impressione è che sia potente, ma forse ha bisogno di un po' più di lavoro prima che sia davvero lucido.

Se c'è una cosa che voglio comunicare qui, però: per favore, non vedi Unit Testing come una mera 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 trattato: il tempo extra dovuto all'uso di PHPUnit sarà

1. più in alto all'inizio poiché lo stai imparando e
2. diminuisci il tempo di sviluppo senza test quando acquisisci sicurezza con esso.

Le classi di modelli di test unitari che non hanno a che fare con la presentazione sono piuttosto semplici. Si scrive un test per ogni classe e in quei casi di test è possibile creare un'istanza e configurare direttamente un oggetto per testare un particolare metodo / funzionalità. Una volta installato e in esecuzione PHPUnit, sarai in grado di eseguire rapidamente questi test.

Le pagine Web di test delle unità possono essere più complicate. Se utilizzi Zend Framework, Symfony, Smarty o qualsiasi altro motore MVC, ottenere PHPUnit per giocare piacevolmente con loro può richiedere più tempo. Utilizziamo Zend Framework e ho dedicato molto tempo alla creazione di classi base per testare i controller e visualizzare gli script da soli. Data la dimensione di questo progetto, probabilmente stai meglio iniziando con ControllerTestCase .