Configurazione PHP (phpunit.xml) - caricamento in un bootstrap?

Question

Situazione

Stiamo utilizzando PHPUnit nel nostro progetto e si utilizza un phpunit.xml per garantire le cose come backupGlobals è spento.

Per garantire ulteriormente che il percorso di inclusione sia impostato e l'autoloading sia attivo, vengono anche messi in cascata i nostri bootstrap di test. Vale a dire, ogni suite di test e alltests ha uno require_once(__DIR__ . '/../bootstrap.php'); nella parte superiore, fino al livello della cartella di base, dove si legge ovviamente require_once(__DIR__ . '/bootstrap.php'); e il file di bootstrap effettivo risiede.

In sostanza, i nostri test sono autonomi. Puoi chiamare qualsiasi AllTests.php in qualsiasi cartella e qualsiasi *Test.php da solo e verranno eseguiti con la configurazione corretta.

Tranne n. 'Aspetta un momento. '

Questo è vero solo se ci sia costringiamo i nostri sviluppatori di utilizzare phpunit --configuration=path/to/phpunit.xml o sono nella cartella con il phpunit.xml (in modo che PHPUnit tira fuori dalla directory di lavoro corrente quando viene eseguito).

Occasionalmente, ciò rende incredibilmente difficile determinare perché i test sulla macchina di uno sviluppatore si stanno interrompendo e perché sono in esecuzione su un'altra. Ci vuole solo dimenticare che il bootstrap è non l'unica cosa di cui abbiamo bisogno per avere lo stesso ambiente di test. Tieni presente che dal momento che non puoi dimenticare il bootstrap se lo hai provato, perché è nei test stessi, dimenticando altre impostazioni, specialmente quelle di solito opzionali come quella (se ti trovi nella cartella con lo phpunit.xml, viene automaticamente estratto) , è facile.

Infatti, è successo un paio di volte.

Domanda

C'è un modo per fornire che phpunit.xml da utilizzare nel file di test in esecuzione, come ad esempio nel nostro file di bootstrap comodamente onnipresente, piuttosto che fornire a PHPUnit anticipo, essere che con l'interruttore della riga di comando o trovandosi nella sua directory ?

Una rapida occhiata al codice suggerisce la risposta è no - di configurazione veramente bene e sembra essere caricato prima che i file di test sono ancora tirati:

[PHPUnit/TextUI/Command.php] 
... 
if (isset($this->arguments['configuration'])) { 
    $configuration = PHPUnit_Util_Configuration::getInstance(
     $this->arguments['configuration'] 
    ); 
    $phpunit = $configuration->getPHPUnitConfiguration(); 
    ... 

che non avere un senso, visto che la configurazione può contenere test white- o blacklist.

Davvero, non avrebbe senso carico di prova filtri nel test bootstrap stesso, in modo che è la metà del potenziale di configurazione fuori dalla finestra con, ma le bandiere reali comportamentali di PHPUnit ...

[sample of part of our phpunit.xml] 
<phpunit 
    backupGlobals="false" 
    backupStaticAttributes="false" 
    convertErrorsToExceptions="true" 
    convertNoticesToExceptions="true" 
    convertWarningsToExceptions="true" 
    syntaxCheck="false" 
    processIsolation="false" 
    colors="true"> 

... forse con l'eccezione dei "colori" mi sembra una cosa che il test stesso dovrebbe essere in grado di decidere su un certo livello.

Premio di consolazione per ...

Certo, adesso sarei felice di sapere se posso insegnare PHPUnit backupGlobals="false" dal file di bootstrap, se qualcuno conosce un modo.

(se infruttuosa, la risposta pratica io inseguo sarà probabilmente per copiare il phpunit.xml in tutte le sottocartelle. Mi piacerebbe per evitare che la soluzione in quanto crea copie ridondanti, e se mai scelto di modificare un'impostazione ... sì, ahi!)

Answer 1

Risposta diretta: No, non puoi farlo.

Storia più lunga: questo tipo di problema viene risolto meglio modificando le abitudini degli sviluppatori.

Ecco lo facciamo:

• Tutti gli sviluppatori corre sempre il test dalla directory test radice, che ha il solo phpunit.xml con tutta la configurazione necessaria - compreso bootstrap, che istituisce un caricatore automatico di classe .
• Non abbiamo testuites in quanto tali, i test sono raggruppati utilizzando le directory, nessun AllTests.php ovunque, perché non è necessario. PHPUnit può prendere un nome di directory ed eseguire tutti i test al suo interno.
• È ancora possibile eseguire qualsiasi singolo test assegnandogli un percorso o un'intera suite di test (assegnando il percorso alla directory). Deve solo essere fatto dalla directory root dei test tutto il tempo o non funzionerà.

Fare in questo modo significa rinunciare alla libertà di avviare PHPUnit da qualsiasi directory, ma a essere onesti - non mi sento affatto una perdita.

I guadagni sono molto più grandi: la quantità di codice di pulizia è ridotta, gli sviluppatori non possono dimenticare nulla ed i risultati sono quindi coerenti.

Answer 2

La mia soluzione è quella di aggiungere una funzione di bash

function phpu() 
{ 
    phpunit --colors --bootstrap ~/path/to/bootstrap.php "$@"; 
} 

Quindi aggiungere questo a tutti i file Dev .bashrc e possono passare ad usare quello.

Ci piace chiamarli da vim quindi ho dovuto aggiungere questo a .vimrc:. set shellcmdflag=-ic

quindi si aggiunge nmap ;t :! phpu % per eseguire il file di prova si è attualmente in

Answer 3

Si potrebbe aggiornare lo script di avvio (File bat di Windows, o shell su * nix) e avere la logica in là per configurare il percorso di phpunit.xml. Se si trova nella directory corrente, usalo, altrimenti punta a quello principale.

Concordo anche con Anti, tuttavia, che tutti i test devono sempre essere eseguiti, in quanto si desidera garantire che le modifiche, anche in un ramo di directory, non influiscano su altro codice. Pertanto, corri sempre dalla cima dell'albero. Ciò richiede anche che il test venga eseguito rapidamente, ma su PHPUnit non ho avuto alcun problema.

Il mantenimento di PHPUnit.xml in ogni directory sarebbe un incubo di manutenzione, a meno che non sia stato collegato simbolicamente da altri percorsi per garantire l'esistenza di un solo file effettivo.