6

Ho una suite di test PHPUnit che sta causando un errore irreversibile a causa di una definizione di classe che non è stata trovata. Questo, in definitiva, è un fallimento del codice di test stesso e un fallimento da parte dello sviluppatore di rivendicare il test stesso prima di commettere il codice.PHPUnit non continua con i test dopo errore fatale quando si utilizza --process-isolation

Tuttavia, di tanto in tanto accadono cose del genere, e sarebbe meraviglioso se, quando si verifica un errore fatale (indipendentemente da chi sia in definitiva responsabile), il test deve essere semplicemente contrassegnato come un errore, e il resto del la suite di test deve ancora essere eseguita.

Ho letto sull'interruttore --process-isolation e per quanto posso dire, è occuparsi di questo. Poiché ogni test viene eseguito in un processo separato, se il bambino muore a causa di un errore irreversibile, il genitore può continuare a funzionare. In realtà, questo è affermato esplicitamente in questa risposta a una domanda simile: https://stackoverflow.com/a/5340151/84762 che mostra il tipo esatto di output che mi piacerebbe vedere me stesso.

Tuttavia, mi sembra di ottenere lo stesso risultato esatto, indipendentemente dal fatto che io uso la bandiera --process-isolation:

senza isolamento processo

[[email protected] ~]$ /usr/bin/phpunit --colors --verbose --coverage-html "target/coverage" ~/app/zend/tests/application/ 

PHP Fatal error: Class 'Rmd_Database_OldObject' not found in /home/kogi/app/zend/private/models/translate/Poll.php on line 9 
PHP Stack trace: 
PHP 1. {main}() /usr/bin/phpunit:0 
PHP 2. PHPUnit_TextUI_Command::main() /usr/bin/phpunit:46 
PHP 3. PHPUnit_TextUI_Command->run() /usr/share/pear/PHPUnit/TextUI/Command.php:130 
PHP 4. PHPUnit_Runner_BaseTestRunner->getTest() /usr/share/pear/PHPUnit/TextUI/Command.php:150 
PHP 5. PHPUnit_Framework_TestSuite->addTestFiles() /usr/share/pear/PHPUnit/Runner/BaseTestRunner.php:96 
PHP 6. PHPUnit_Framework_TestSuite->addTestFile() /usr/share/pear/PHPUnit/Framework/TestSuite.php:419 
PHP 7. PHPUnit_Util_Fileloader::checkAndLoad() /usr/share/pear/PHPUnit/Framework/TestSuite.php:358 
PHP 8. PHPUnit_Util_Fileloader::load() /usr/share/pear/PHPUnit/Util/Fileloader.php:79 
PHP 9. include_once() /usr/share/pear/PHPUnit/Util/Fileloader.php:95 
PHP 10. require_once() /home/kogi/app/zend/tests/application/translate/PollTest.php:11 

Fatal error: Class 'Rmd_Database_OldObject' not found in /home/kogi/app/zend/private/models/translate/Poll.php on line 9 

Call Stack: 
    0.0003  91584 1. {main}() /usr/bin/phpunit:0 
    0.0076  612672 2. PHPUnit_TextUI_Command::main() /usr/bin/phpunit:46 
    0.0076  613744 3. PHPUnit_TextUI_Command->run() /usr/share/pear/PHPUnit/TextUI/Command.php:130 
    0.0246 1249464 4. PHPUnit_Runner_BaseTestRunner->getTest() /usr/share/pear/PHPUnit/TextUI/Command.php:150 
    0.0706 1626680 5. PHPUnit_Framework_TestSuite->addTestFiles() /usr/share/pear/PHPUnit/Runner/BaseTestRunner.php:96 
    0.1691 8053584 6. PHPUnit_Framework_TestSuite->addTestFile() /usr/share/pear/PHPUnit/Framework/TestSuite.php:419 
    0.1693 8057320 7. PHPUnit_Util_Fileloader::checkAndLoad() /usr/share/pear/PHPUnit/Framework/TestSuite.php:358 
    0.1694 8057664 8. PHPUnit_Util_Fileloader::load() /usr/share/pear/PHPUnit/Util/Fileloader.php:79 
    0.1711 8240600 9. include_once('/home/kogi/app/zend/tests/application/translate/PollTest.php') /usr/share/pear/PHPUnit/Util/Fileloader.php:95 
    0.1805 9187768 10. require_once('/home/kogi/app/zend/private/models/translate/Poll.php') /home/kogi/app/zend/tests/application/translate/PollTest.php:11 

CON isolamento del processo

[[email protected] ~]$ /usr/bin/phpunit --colors --verbose --coverage-html "target/coverage" --process-isolation ~/app/zend/tests/application/ 
PHP Fatal error: Class 'Rmd_Database_OldObject' not found in /home/kogi/app/zend/private/models/translate/Poll.php on line 9 
PHP Stack trace: 
PHP 1. {main}() /usr/bin/phpunit:0 
PHP 2. PHPUnit_TextUI_Command::main() /usr/bin/phpunit:46 
PHP 3. PHPUnit_TextUI_Command->run() /usr/share/pear/PHPUnit/TextUI/Command.php:130 
PHP 4. PHPUnit_Runner_BaseTestRunner->getTest() /usr/share/pear/PHPUnit/TextUI/Command.php:150 
PHP 5. PHPUnit_Framework_TestSuite->addTestFiles() /usr/share/pear/PHPUnit/Runner/BaseTestRunner.php:96 
PHP 6. PHPUnit_Framework_TestSuite->addTestFile() /usr/share/pear/PHPUnit/Framework/TestSuite.php:419 
PHP 7. PHPUnit_Util_Fileloader::checkAndLoad() /usr/share/pear/PHPUnit/Framework/TestSuite.php:358 
PHP 8. PHPUnit_Util_Fileloader::load() /usr/share/pear/PHPUnit/Util/Fileloader.php:79 
PHP 9. include_once() /usr/share/pear/PHPUnit/Util/Fileloader.php:95 
PHP 10. require_once() /home/kogi/app/zend/tests/application/translate/PollTest.php:11 

Fatal error: Class 'Rmd_Database_OldObject' not found in /home/kogi/app/zend/private/models/translate/Poll.php on line 9 

Call Stack: 
    0.0003  91752 1. {main}() /usr/bin/phpunit:0 
    0.0076  612824 2. PHPUnit_TextUI_Command::main() /usr/bin/phpunit:46 
    0.0076  613896 3. PHPUnit_TextUI_Command->run() /usr/share/pear/PHPUnit/TextUI/Command.php:130 
    0.0246 1250360 4. PHPUnit_Runner_BaseTestRunner->getTest() /usr/share/pear/PHPUnit/TextUI/Command.php:150 
    0.0708 1627528 5. PHPUnit_Framework_TestSuite->addTestFiles() /usr/share/pear/PHPUnit/Runner/BaseTestRunner.php:96 
    0.1688 8054296 6. PHPUnit_Framework_TestSuite->addTestFile() /usr/share/pear/PHPUnit/Framework/TestSuite.php:419 
    0.1690 8057992 7. PHPUnit_Util_Fileloader::checkAndLoad() /usr/share/pear/PHPUnit/Framework/TestSuite.php:358 
    0.1691 8058336 8. PHPUnit_Util_Fileloader::load() /usr/share/pear/PHPUnit/Util/Fileloader.php:79 
    0.1707 8241296 9. include_once('/home/kogi/app/zend/tests/application/translate/PollTest.php') /usr/share/pear/PHPUnit/Util/Fileloader.php:95 
    0.1801 9188464 10. require_once('/home/kogi/app/zend/private/models/translate/Poll.php') /home/kogi/app/zend/tests/application/translate/PollTest.php:11 

Per quelli di noi che non possono diff in modo efficace nelle nostre teste, le due uscite sono letteralmente identiche (a parte il tempo di esecuzione e l'utilizzo della memoria che è trascurabilmente diverso).

In entrambi i casi, l'errore fatale uccide l'intera suite di test. In questo caso particolare, ciò avviene nel terzo test e i restanti 150 test (in molti altri file/suite) non vengono mai eseguiti.

Cosa sto facendo di sbagliato qui? C'è un altro modo per sopravvivere a un errore fatale (contrassegnando il test come fallito) in un test ed eseguire ancora test rimanenti?


EDIT

sto utilizzando PHPUnit 3.6.10

EDIT

Commenti sulla risposta a questa domanda hanno ispirato un nuovo biglietto a pagina GitHub di PHPUnit: https://github.com/sebastianbergmann/phpunit/issues/545

+0

Qui troverai la tua risposta: http: // stackoverflow.it/questions/277224/how-do-i-catch-a-php-fatal-error – alfasin

+1

Non sono sicuro se ti riferisci alla parte che dice che non possono essere scoperti o alla parte che dice che non dovrebbero essere catturati ... ma entrambe le affermazioni sono false. In questo caso, quando si verifica la funzionalità di un sistema, è molto importante rilevare errori irreversibili senza uccidere il resto del processo di test. Se sto fraintendendo la tua risposta, mi scuso, faccelo sapere. – KOGI

+0

Mi riferivo alla parte che dice che non può essere catturata. È vero che puoi usare register_shutdown_function per stampare cose da loggare e fare "clean up" ma dal momento che il frame è già stato distrutto (in pila) non credo che tu possa "riprendere" il tuo programma. Poiché sai esattamente su quale riga è stato attivato l'errore fatale: perché non risolverlo? – alfasin

risposta

5

PHPUnità carica ciascun file di prova che verrà eseguito prima di eseguire qualsiasi test. Questo fa sì che PHP analizzi questi file ed esegua il loro codice di primo livello. Se viene caricata una classe che, ad esempio, estende una classe che non esiste, si verificherà un errore irreversibile.

Non vedo alcun modo per aggirare questo senza migliorare PHPUnit per analizzare i file senza eseguire il codice durante il processo di scansione.

+0

E 'ancora così quando usi '--process-isolation'? – KOGI

+0

Sì, ho eseguito un test modificando un test di lavoro per estendere una classe con nome errato e si arresta anche con isolamento. –

+0

Beh, dannazione! Torna al punto di partenza! Grazie. – KOGI

Problemi correlati