How to contribute to Symfony Version: master

Transcript

1 How to contribute to Symfony Version: master

2 How to contribute to Symfony (master) This work is licensed under the Attribution-Share Alike 3.0 Unported license ( licenses/by-sa/3.0/). You are free to share (to copy, distribute and transmit the work), and to remix (to adapt the work) under the following conditions: Attribution: You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). Share Alike: If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license. For any reuse or distribution, you must make clear to others the license terms of this work. The information in this book is distributed on an as is basis, without warranty. Although every precaution has been taken in the preparation of this work, neither the author(s) nor SensioLabs shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in this work. If you find typos or errors, feel free to report them by creating a ticket on the Symfony ticketing system ( Based on tickets and users feedback, this book is continuously updated.

3 Contents at a Glance Segnalare un bug...4 Inviare una patch...5 La squadra di Symfony... Problemi di sicurezza...5 Eseguire i test di Symfony...9 Promessa di retrocompatibilità... Standard del codice...3 Convenzioni...34 Git...36 Licenza di Symfony...37 Contribuire alla documentazione...38 Formato della documentazione...44 Standard di documentazione...48 Traduzioni...5 Licenza della documentazione di Symfony...53 Il processo di rilascio...55 Altre risorse...59 Contents at a Glance iii

4 Chapter Segnalare un bug Se doveste incontrare un bug in Symfony, vi chiediamo di segnalarlo. Ci aiuta a rendere migliore Symfony. Se pensate di aver trovato un problema di sicurezza, per favore, seguite invece l'apposita procedura. Prima di inviare un bug: Ricontrollare la documentazione ufficiale per verificare che non si stia facendo un uso scorretto del framework; Chiedere assistenza alla lista degli utenti, al forum 3 o al canale IRC 4 #symfony, se non si è sicuri che sia effettivamente un bug. Se il problema è effettivamente un bug, segnalarlo utilizzando il bug tracker 5 ufficiale e seguendo alcune regole: Utilizzare il campo titolo per descrivere chiaramente la questione; Descrivere i passi necessari per riprodurre il bug con brevi esempi di codice (la cosa migliore è fornire un test unitario per replicare il bug) Se il bug riscontrato affligge più livelli, fornire un semplice test unitario che fallisca potrebbe non essere sufficiente. In questo caso, eseguire un fork di Symfony Standard Edition 6 e riprodurre il problema su un nuovo ramo; Fornire il maggior numero di dettagli possibile sul proprio ambiente (sistema operativo, versione PHP versione di Symfony, estensioni abilitate,...) (facoltativo) Allegare una patch #contributing-code-irc:--irc.freenode.net-symfony Chapter : Segnalare un bug 4

5 Chapter Inviare una patch Una patch è il modo migliore per rimediare a un bug e per proporre dei miglioramenti a Symfony Passo : preparare l'ambiente Installare il software Prima di lavorare con Symfony, preparare l'ambiente con il seguente software: Git; PHP versione o successive; PHPUnit o successivi. Configurare Git Impostare le informazioni utente con il proprio nome reale e il proprio indirizzo di posta elettronica: Listing - $ git config --global user.name "nome" $ git config --global user. @example.com Si raccomanda caldamente a chi fosse nuovo la lettura del libro ProGit, eccellente e libero. Se si usa un IDE che crea file di configurazione dentro la cartella del progetto, si può usare il file globale.gitignore (per tutti i progetti) o il file.git/info/exclude (per progetto) per ignorarli. Vedere la documentazione di Github.. Chapter : Inviare una patch 5

6 Utenti di Windows: quando si installa Git, l'installazione chiederà cosa fare con i fine riga, suggerendo di sostituire Lf con CRLF. Questa impostazine è sbagliata, se si vuole contribuire a Symfony! Impostare il metodo "as-is" come scelta migliore, così git convertirà i fine riga con quelli nel repository. Se git è già stato installato, si può verificare questa impostazione con: Listing - $ git config core.autocrlf Restituirà "false", "input" o "true", dove "true" e "false" sono i valori sbagliati. Impostare nuovamente con: Listing -3 $ git config --global core.autocrlf input Sostituire --global con --local se si vuole impostare solo per il repository attivo. Ottenere il codice sorgente di Symfony Ottenere il codice sorgente di Symfony: Creare un account su GitHub 3 ed entrare; Forkare il repository di Symfony 4 (cliccando sul bottone "Fork"); Dopo che l'azione "hardcore forking" è stata completata, clonare il fork in locale (creerà una cartella symfony): Listing -4 $ git clone git@github.com:username/symfony.git Aggiungere il repository upstream come remote: Listing -5 $ cd symfony $ git remote add upstream git://github.com/symfony/symfony.git Verificare che i test passino Ora che Symfony è installato, verifcare che tutti i test unitari passino nel proprio ambiente, come spiegato nel documento dedicato. Passo : lavorare su una patch La licenza Prima di iniziare, occorre sapere che tutte le patch da inviare devono essere rilasciate sotto licenza MIT, a meno che non sia specificato diversamente nel proprio commit Chapter : Inviare una patch 6

7 Scegliere il ramo giusto Prima di lavorare su una patch, è necessario individuare il ramo giusto. Il ramo deve essere basato sul ramo master, se si vuole aggiungere una nuova funzionalità. Ma se si vuole risolvere un bug, utilizzare le versioni vecchie (ma ancora mantenute) di Symfony nelle quali appare il bug (come.). Tutti i bug risolti in rami di manutenzione sono inseriti anche i rami più recenti, su base regolare. Per esempio, se si invia una patch per il ramo.3, la patch sarà applicata anche sul ramo master. Creare un ramo Ogni volta che si vuole lavorare su una patch per un bug o un miglioramento, creare un ramo: Listing -6 $ git checkout -b NOME_RAMO master Oppure, se si vuole risolvere un bug per il ramo.3, tracciare il ramo.3 remoto in locale: Listing -7 $ git checkout -t origin/.3 Quindi creare un nuovo ramo dal ramo.3: Listing -8 $ git checkout -b NOME_RAMO.3 Usare un nome descrittivo per il ramo (ticket_xxx, dove XXX è il numero di ticket, è una buona convenzione per i bug). I comandi precedenti porteranno automaticamente sul ramo appena creato (verificare il ramo su cui si sta lavorando con git branch). Lavorare su una patch È possibile lavorare sul codice quanto si vuole e committare tanto quanto si vuole; ma bisogna tenere a mente le seguenti indicazioni: Seguire le convenzioni di Symfony e gli standard del codice (utilizzare git diff --check per controllare i spazi alla fine); Aggiungere test unitari per provare che il bug è stato risolto o per mostrare che la funzionalità è effettivamente funzionante; Sforzarsi di non infrangere la retrocompatibilità (se lo si deve fare, provare a fornire un livello di compatibilità che supporti il vecchio modo), le patch che infrangono la retrocompatbilità hanno meno probabilità di essere accettate; Fare commit separati e atomici (utilizzare le funzionalità di git rebase per ottenere uno storico chiaro e pulito); Comprimere i commit irrilevanti, che sistemano solamente gli standard di codice o gli errori di battitura; Non sistemare mai gli standard nel codice esistente, perché rende più difficoltosa la revisione del codice; Scrivere buoni messaggi di commit. Chapter : Inviare una patch 7

8 Quando si inviano richieste di pull, fabbot 5 può verificarne il codice, cercando errori comuni e controllando gli standard di codice definiti in PSR- 6 e PSR- 7. Uno stato viene inviato sotto alla descrizione della richiesta di pull, con un sommario di eventuali problemi trovati o fallimenti delle build di Travis CI. Un buon messaggio di commit è composto dal riepilogo nella (prima linea), opzionalmente seguito da una linea vuota e da una descrizione dettagliata. Il riepilogo dovrebbe cominciare con il componente sul quale si sta lavorando, posto fra parentesi quadre ([DependencyInjection], [FrameworkBundle],...). Utilizzare un verbo (fixed..., added...,...) per iniziare e non utilizzare il punto finale. Preparare la patch per l'invio Quando una patch non riguarda la sistemazione di un bug (quando si aggiunge una nuova caratteristica o se ne cambia una, per esempio), occorre includere quello che segue: Una spiegazione delle modifiche nel file (o nei file) CHANGELOG rilevante (usare il prefisso [BC BREAK] o [DEPRECATION], se rilevanti); Una spiegazione di come aggiornare un'applicazione esistente, nel file (o nei file) UPGRADE rilevante, se le modifiche infrangono la retrocompatibilità o se si sta deprecando qualcosa che alla fine infrangerà la retrocompatibilità. Passo 3: inviare la patch Quando si ritiene che la patch sia pronta per l'invio, seguire i passi seguenti. Fare un rebase Prima di inviare una patch, aggiornare il ramo (necessario se passa del tempo tra il checkout e il commit delle nuove funzionalità) Listing $ git checkout master $ git fetch upstream $ git merge upstream/master $ git checkout NOME_RAMO $ git rebase master Sostituire master con il ramo su cui si sta lavorando (p.e..5) sulla risoluzione di un bug Quando si esegue il comando rebase, potrebbe essere necessario risolvere conflitti. Il comando git status metterà in mostra i file non ancora uniti (unmerged ). Risolvere tutti i conflitti e continuare con il rebase: Chapter : Inviare una patch 8

9 Listing -0 $ git add... # aggiunge file risolti $ git rebase --continue Verificare che tutti i test stiano ancora passando e inviare gli sviluppi nel ramo remoto. Listing - $ git push origin NOME_RAMO Richiedere un pull Si può ora eseguire una richiesta di pull sul repository symfony/symfony su Github. Si faccia attenzione a puntare la richiesta di pull verso symfony:.3, se si vuole che la risoluzione del bug riceva un pull basato sul ramo.3. Per facilitare il lavoro, includere sempre i componenti modificati nel messaggio di richiesta di pull, come in: Listing - [Yaml] sistemato qualcosa [Form] [Validator] [FrameworkBundle] aggiunto qualcosa La descrizione della richiesta di pull deve includere la seguente lista in cima, per assicurare che i contributi siano rivisti senza continui giri di feedback e che quindi possano essere inclusi in Symfony il prima possibile: Listing Q A Bug fix? [yes no] New feature? [yes no] BC breaks? [yes no] Deprecations? [yes no] Tests pass? [yes no] Fixed tickets [lista separata da virgole di ticket risolti nella PR] License MIT Doc PR [Riferimento alla PR di documentazione, se presente] Un esempio di proposta potrebbe essere il seguente: Listing Q A Bug fix? no New feature? no BC breaks? no Deprecations? no Tests pass? yes Fixed tickets #, #43 License MIT Doc PR symfony/symfony-docs#3 L'intera tabella va inclusa (non rimuovere le righe che si ritengono non rilevanti). Per sempici errori di battitura, modifiche minori in PHPDoc o modifiche nei file di traduzione, usare la versione breve della lista: Listing -5 Chapter : Inviare una patch 9

10 3 4 Q A Fixed tickets [lista separata da virgole di ticket risolti nella PR] License MIT Alcune risposte alle domande richiedono ulteriori requisiti: Se si risponde affermativamente a "Bug fix?", verificare se il bug sia già elencato tra le issue di Symfony e referenziarlo in "Fixed tickets"; Se si risponde affermativamente a "New feature?", si deve inviare una richiesta di pull alla documentazione e referenziarla sotto la sezione "Doc PR"; Se si risponde affermativamente a "BC breaks?", la patch deve contenere aggiornamenti ai file CHANGELOG e UPGRADE rilevanti; Se si risponde affermativamente a "Deprecations?", la patch deve contenere aggiornamenti ai file CHANGELOG e UPGRADE rilevanti; Se si risponde negativamente a "Tests pass", si deve aggiungere un elemento a una lista di todo con le azioni da eseguire per sistemare i test; Se "license" non è MIT, non inviare la richiesta di pull, perché non sarà comunque accettata. Se alcuni dei precedenti requisiti non sono soddisfatti, creare una lista di todo e aggiungere gli elementi rilevanti: Listing [ ] fix the tests as they have not been updated yet - [ ] submit changes to the documentation - [ ] document the BC breaks Se il codice non è finito perché non si ha il tempo di finirlo o perché si desidera prima un feedback, aggiungere un elemento alla lista di todo: Listing -7 - [ ] finish the code - [ ] gather feedback for my changes Finché si hanno elementi nella lista di todo, si prega di aggiungere alla richiesta di pull il prefisso "[WIP]". Nella descrizione della richiesta di pull, dare quanti più dettagli possibile sulle proprie modifiche (non esitare a fornire esempi di codice per illustrare il punto). Se la richiesta di pull aggiunge nuove caratteristiche o ne modifica di esistenti, spiegare le ragioni delle modifiche. La descrizione della richiesta di pull aiuta la revisione del codice e serve da riferimento nel momento del merge (la descrizione della richiesta di pull e tutti i commenti associati sono parte del messaggio di commit del merge). Oltre alla richiesta di pull sul codice, si deve inviare anche una richiesta di pull al repository della documentazione 8, per aggiornare la documentazione relativa. Rielaborare una patch Dipendentemente dal riscontro della lista o attraverso la richiesta di pull su Github, potrebbe essere necessario rielaborare la patch. Prima di re-inserire la patch, eseguire il rebase con il ramo master, ma non unire attraverso il merge; e forzare il push nell'origin: Listing -8 $ git rebase -f upstream/master $ git push --force origin NOME_RAMO 8. Chapter : Inviare una patch 0

11 Quando si fa un push --force, specificare sempre il nome del ramo in modo esplicito, per evitare complicazioni con altri rami del repository (--force dice a git che si vogliono veramente complicare le cose, quindi va usato con cautela). Spesso, i moderatori richiederanno una compressione dei commit. Questo vuol dire che si convertiranno molti commit in uno solo. Per farlo, usare il comando rebase: Listing -9 $ git rebase -i upstream/master $ git push --force origin NOME_RAMO Dopo aver scritto questo comando, si aprirà un programma di modifica, con una lista di commit: Listing -0 3 pick a3be6 primo commit pick 7fc64b4 secondo commit pick 7d3308 terzo commit Per unificare tutti i commit nel primo, rimuovere la parola pick prima del secondo e dell'ultimo commit e sostituirla con la parola squash, o anche solo s. Quando si salva, git inizierà il rebase e, in caso di successo, chiederà di modificare il messaggio di commit, che come predefinito è una lista di messaggi di commit di tutti i commit. Dopo aver finito, eseguire il push. Chapter : Inviare una patch

12 Chapter 3 La squadra di Symfony Questo documento elenca le regole che governano la squadra di Symfony. Tali regole sono effettive a partire dalla pubblicazione di questo domento e tutti i membri della squadra di Symfony devono rispettarle. Organizzazione I membri della squadra di Symfony sono divisi in tre gruppi. Ciascun membro può appartenere a un solo gruppo alla volta. I privilegi garantiti a un gruppo sono automaticamente estesi a ogni gruppo che abbia priorità maggiore. I gruppi della squadra di Symfony, in ordine decrescente di priorità, sono i seguenti:. Capo progetto Elegge i membri degli altri gruppi; Esegue i merge delle richieste di pull in tutti i repoistory di Symfony.. Merger Eseguono i merge delle richieste di pull per i componenti che sono stati loro assegnati. 3. Decider Decidono per un merge o un rifiuto di una richiesta di pull. Membri attivi Capo progetto: Fabien Potencier (fabpot). Merger: Chapter 3: La squadra di Symfony

13 Bernhard Schussek (webmozart) per i componenti Form, Validator, Icu 3, Intl 4, Locale 5, OptionsResolver 6 e PropertyAccess 7 ; Tobias Schultze (Tobion) per il componente Routing 8 ; Romain Neutron (romainneutron) per il componente Process 9 ; Nicolas Grekas (nicolas-grekas) per il componente Debug 0. Christophe Coevoet (stof) per i componenti BrowserKit, Config, Console 3, DependencyInjection 4, DomCrawler 5, EventDispatcher 6, HttpFoundation 7, HttpKernel 8, Serializer 9, Stopwatch 0, DoctrineBridge, MonologBridge, e TwigBridge 3. Decider: Jakub Zalas (jakzal); Jordi Boggiano (seldaek); Lukas Kahwe Smith (lsmith77). Richiesta di affiliazione Al momento non si accettano richieste di nuovi membri per la squadra di Symfony. Revoca dall'affiliazione Un membro della squadra di Symfony può essere espulso per una delle seguenti ragioni: Rifiuto di seguire le regole elencate in questo documento; Mancanza di attività nei sei mesi precedenti; Negligenza deliberata o intenzione di danneggiare il progetto Symfony; Su decisione del capo progetto. Se in futuro saranno accettati nuovi membri, i membri espulsi dovranno attendere dodici mesi prima di richiedere una riammissione Chapter 3: La squadra di Symfony 3

14 Regole sullo sviluppo del codice Lo sviluppo del progetto Symfony si basa su richeiste di pull, proposte da qualsiasi membro della comunità di Symfony. L'accettazione o il rifiuto delle richieste di pull sono decisi in base ai voti espressi dai membri della squadra di Symfony. Votazione delle richieste di pull I voti - vanno sempre giustificati con ragioni tecniche e oggettive; I voti + non richiedono giustificazioni, a meno che non ci sia almeno un voto -; I membri della squadra possono modificare i propri voti in qualsiasi momento, nel corso della discussione su una richiesta di pull; Un membro della squadra non può votare una sua richiesta di pull. Merge delle richieste di pull Si può esegeuire il merge di una richiesta di pull se: Sia passsato abbastanza tempo per le revisioni (alcuni minuti per le modifiche minori, almeno due giorni per le richieste di pull "normali" e quattro giorni per le richieste di pull con "impatto significativo"); Sia una modifica minore [], indipendentemente dal numero di voti; Almeno il merger del componente o altri due membri della squadra abbiano votato + e nessun altro membro abbia votato -. Processo di merge delle richieste di pull Tutto il codice deve passare per richieste di pull, tranne le modifiche minori [], che possono essere committate direttamente nel repository. I merger devono usare sempre lo strumento gh, fornito dal capo progetto, per il merge delle richieste di pull. Rilasci Il capo progetto è anche il gestore dei rilasci di ogni versione di Symfony. Emendamenti alle regole Le regole descritte in questo documento potranno essere emendate in qualsiasi momento, a discrezione del capo progetto [] (, ) Le modifiche minori includono errori di battitura, sistemazioni di DocBlock, violazioni agli standard del codice, modifiche minori a CSS, JavaScript e HTML. Chapter 3: La squadra di Symfony 4

15 Chapter 4 Problemi di sicurezza Questo documento spiega la gestione da parte della squadra di Symfony dei problemi di sicurezza di Symfony (in cui "Symfony" è il codice ospitato nel repository Git symfony/symfony). Segnalare un problema di sicurezza Se si è trovato un problema di sicurezza in Symfony, non utilizzare la lista o il bug tracker e non diffonderlo pubblicamente. Tutte le questioni di sicurezza devono essere inviate a security [at] symfony-project.com. Le inviate a questo indirizzo verranno inoltrate alla squadra di sviluppo di Symfony. Processo di risoluzione Per ogni rapporto, prima si cercherà di confermare la vulnerabilità. Quando confermata, la squadra di sviluppo lavorerà a una soluzione seguendo questi passi:. Inviare un riconoscimento al segnalatore;. Lavorare su una patch; 3. Ottenere un identificatore CVE da mitre.org; 4. Scrivere un annuncio sul blog di Symfony, che descriva la vulnerabilità. Tale post dovrebbe contenere le seguenti informazioni: un titolo che includa sempre la stringa "Security release"; una descrizione della vulnerabilità; le versioni afflitte; i possibili exploit; come applicare patch/aggiornamenti/workaround alle applicazioni afflitte; l'identificatore CVE; riconoscimenti. 5. Inviare patch e annuncio al segnalante per una revisione;. Chapter 4: Problemi di sicurezza 5

16 6. Applicare la patch a tutte le versioni di Symfony in manutenzione; 7. Pacchettizzare nuove versioni per tutte le versioni afflitte; 8. Pubblicare il post sul blog 3 ufficiale di Symfony (va anche aggiunti alla categoria "Security Advisories 4 "); 9. Aggiornare la lista degli avvisi di sicurezza (vedere sotto). I rilasci che includono questioni di sicurezza non andrebbero fatti di sabato o domenica, a meno che la vulnerabilità non sia stata resa pubblica. Mentre la patch è in corso di lavorazione, si prega di non rivelare pubblicamente la problematica. La risoluzione può prendere tra un paio di giorni a un mese, a seconda della complessità e del coordinamento tra i progetti a valle (vedere il paragrafo successivo). Collaborazione con progetti open source a valle Poiché Symfony è usato da molti progetti open source, il modo in cui la squadra di sicurezza di Symfony collabora sulle problematiche di sicurezza è stata standardizzata con i progetti a valle. Il progetto funziona come segue:. Dopo che la squadra di sicurezza di Symfony ha riconosciuto la problematica, invia immediatamente una alle squadre di sicurezza dei progetti a valle, per informarli della probelamtica;. La squadra di sicurezza di Symfony crea un repository Git privato, per facilitare la collaborazione sulla problematica. L'accesso a tale repository è fornito all squadra di sicurezza di Symfony, ai contributori du Symfony che hanno avuto impatto sulla problematica e a un rappresentante i ogni progetto a valle; 3. Le persone che accedono al repository privato lavorano a una soluzione per risolvere la problematica, tramire richieste di pull, revisioni di codice e commenti; 4. Una volta trovata la soluzione, tutti i progetti coinvolti collaborano per trovare la data migliore per un rilascio congiunto (non c'è garanzia che tutti i rllasci saranno contempoaranei, ma si tenterà il più possibili di pubblicarli nello stesso periodo). Quando non si ritiene che la problematica abbia subito degli exploit, un periodo di due settimane sembra essere ragionevole. La lista dei progetti a valle partecipanti a tale processo è manutenuta più corta possibile, per meglio gestire il flusso di informazioni riservate, prima della pubblicazione. Per questo motivo, i progetti saranno inclusi a sola discrezione della squadra di sicurezza di Symfony. A oggi, i seguenti progetti hanno approvato questo processo e sono parte dei progetti a valle inclusi: Drupal (solitamente con rilasci di venerdì) ezpublish Chapter 4: Problemi di sicurezza 6

17 Bollettini di sicurezza Questa sezione elenca le vulnerabilità di sicurezza che sono state risolte in Symfony, partendo da Symfony.0.0: 5 luglio 04: Security releases: Symfony.3.8,.4.8, and.5. released 5 (CVE ) 0 ottobre 03: Security releases: Symfony.0.5,..3,..9, and.3.6 released 7 (CVE ) 7 agosto 03: Security releases: Symfony.0.4,..,..5, and.3.3 released 9 (CVE and CVE ) 7 gennaio 03: Security release: Symfony.0. and..7 released (CVE and CVE ) 0 dicembre 0: Security release: Symfony.0.0 and..5 5 (CVE and CVE ) 9 novembre 0: Security release: Symfony.0.9 and novembre 0: Security release: symfony.4.0 released 9 8 agosto 0: Security Release: Symfony.0.7 released 0 30 maggio 0: Security Release: symfony.4.8 released 4 febbraio 0: Security Release: Symfony.0. released 6 novembre 0: Security Release: Symfony marzo 0: symfony.3.0 and.4.0: security releases 4 9i giugno 00: Security Release: symfony.3.6 and maggio 00: symfony.3.5 and febbraio 00: Security Release:..,.3.3 and febbraio, 00: symfony.3. and aprile 009: symfony..6: Security fix 9 3 ottobre 008: symfony..4 released: Security fix 30 4 maggio 008: symfony.0.6 is out 3 aprile 008: symfony.0.3 is out Chapter 4: Problemi di sicurezza 7

18 marzo 008: symfony.0. is (finally) out! 33 5 giugno 007: symfony.0.5 released (security fix) Chapter 4: Problemi di sicurezza 8

19 Chapter 5 Eseguire i test di Symfony Prima di inviare una patch, occorre eseguire tutti i test di Symfony, per assicurarsi di non aver rotto nulla. PHPUnit Per eseguire i test di Symfony, installare prima PHPUnit 3.7 o successivi. Dipendenze (opzionali) Per eseguire tutti i test, inclusi quelli che hanno dipendenze esterne, Symfony deve poterle scaricare. Per impostazione predefinita, sono auto-caricati dalla cartella vendor/ (vedere autoload.php.dist). I test necessitano delle seguenti librerie di terze parti: Doctrine Swift Mailer Twig Monolog Per installarle tutte, usare Composer : Passo : installare Composer 3 Listing 5- $ curl -s php Assicurasi di scaricare composer.phar nella stessa cartella in cui si trova il file composer.json. Passo : installare i venditori Listing Chapter 5: Eseguire i test di Symfony 9

20 $ php composer.phar --dev install Si noti che lo script ha bisogno di tempo per terminare. Se non si ha curl installato, si può anche scaricare a mano il file installer da 4. Mettere tale file nel progetto ed eseguirlo: Listing 5-3 $ php installer $ php composer.phar --dev install Dopo l'installazione, si possono aggiornare i venditori alle loro ultime versioni, con il comando seguente: Listing 5-4 $ php composer.phar --dev update Esecuzione Prima di tutto, aggiornare i venditori (vedere sopra). Quindi, eseguire i test dalla cartella radice di Symfony, con il comando seguente: Listing 5-5 $ phpunit L'output dovrebbe mostrare OK. Altrimenti, occorre appurare quello che si è verificato e se i test sono rotti per colpa di una propria modifica. Se si vuole testare un singolo componente, scriverne il percorso dopo il comando phpunit, p.e.: Listing 5-6 $ phpunit src/symfony/component/finder/ Eseguire i test prima di applicare le proprie modifiche, per assicurarsi che girino correttamente con la propria configurazione. Copertura del codice Se si aggiunge una nuova caratteristica, occorre anche verificare la copertura del codice, usando l'opzione coverage-html: Listing 5-7 $ phpunit --coverage-html=cov/ 4. Chapter 5: Eseguire i test di Symfony 0