web-dev-qa-db-fra.com

PHPUnit - ne fait rien, pas d'erreurs, pas de sortie

Désolé pour une autre question "phpunit ne fonctionne pas". Cela fonctionnait depuis des années maintenant. Aujourd'hui, j'ai réinstallé PEAR et phpunit pour des raisons non liées à ce problème. Maintenant, quand je lance phpunit comme d'habitude. Rien ne se passe. La cli me montre juste une nouvelle ligne, aucune sortie que ce soit.

Quelqu'un a-t-il rencontré ce problème ou a-t-il une idée de ce qui aurait pu le provoquer?.

PHPUnit Version: 3.5.15 
PEAR Version: 1.9.4 
PHP Version: 5.3.8 
Windows 7
phpunit
39
markus

Créez la classe de test la plus simple possible sans bootstrap.php ou phpunit.xml pour vérifier au préalable que votre nouvelle installation fonctionne. PHPUnit s'arrêtera sans message s'il ne peut pas instancier tous les tests - un pour chaque méthode de test et fournisseur de données - avant d'exécuter des tests.

21
David Harkness

Je suis sur OSX et MAMP. Pour obtenir des messages d'erreur, j'ai dû ajuster les entrées suivantes dans php.ini:

display_errors = On
display_startup_errors = On

S'il vous plaît ne pas que cela doit aller dans /Applications/MAMP/bin/php/php5.3.6/conf/php.ini.

53
BetaRide

Pour référence future, pour ceux qui rencontrent un problème avec PHPUnit, et PHPUnit échoue en silence, ajoutez simplement ces trois lignes dans phpunit.xml:

<phpunit ....... >
    ...
    ...
    <php>
         <ini name="display_errors" value="true"/>
    </php>
</phpunit>

Après cela, relancez les tests, et vous pouvez maintenant voir pourquoi PHPUnit échoue,

ET ... PROFITEZ DES TESTS UNITAIRES :)

36
Ahmad Hajjar

Je sais que la question de l'affiche originale a déjà été résolue, mais pour quiconque cherche dans le futur: une chose qui peut faire échouer PHPUnit en mode silencieux (c'est-à-dire qu'elle arrête simplement d'exécuter des tests sans vous dire pourquoi) est qu'elle comporte un gestionnaire d'erreurs. configuré avant chaque test, destiné à capturer les erreurs et à les afficher à la fin du test. Le problème est que certaines erreurs arrêtent l'exécution de la totalité du test.

Ce que je fais généralement lorsque cela se produit, dans un premier temps, consiste à réinitialiser le gestionnaire d'erreurs sur quelque chose qui produira immédiatement le message d'erreur. Dans ma classe de test de base, j'ai une méthode appelée setVerboseErrorHandler, que j'appellerai en haut du test (ou dans setUp) lorsque cela se produira. Ce qui suit nécessite PHP 5.3 ou supérieur (en raison de la fermeture), donc si vous êtes sur 5.2 ou inférieur, vous pouvez en faire une fonction régulière.

protected function setVerboseErrorHandler() 
{
    $handler = function($errorNumber, $errorString, $errorFile, $errorLine) {
        echo "
ERROR INFO
Message: $errorString
File: $errorFile
Line: $errorLine
";
    };
    set_error_handler($handler);        
}
27
Isaac

Vous avez déjà compris comment le faire fonctionner, mais ma solution était un peu différente.

La première chose à faire est de vérifier l’état de sortie. Si ce n'est pas 0, alors PHP s'est arrêté et, en raison des paramètres de configuration INI définis, aucun des messages d'erreur PHP n'a été généré. Ce que j'ai fait est d'activer le paramètre "display_errors" INI et de définir "error_reporting" sur E_ALL. J'ai alors pu identifier des erreurs telles que PHP ne pas être en mesure d'analyser un certain script. Une fois que j'ai corrigé cela, PHPUnit a fonctionné correctement.

6
Kevin Herrera

J'ai réussi à me peindre de façon spectaculaire dans un coin avec un "gestionnaire d'erreurs fatales" personnalisé qui, dans certaines conditions rares, s'est avéré être une sortie rien . Ces conditions, conformément à la loi de Murphy, se sont matérialisées une fois que j'ai oublié que le gestionnaire était en place.

Comme ce n’était pas vraiment un "problème PHPunit", aucune des autres réponses n’a aidé [bien que le problème de @ David soit au fond la même chose], même si les symptômes étaient les mêmes: connectez-vous et aucun indice.

Finalement, j'ai dû recourir à un traçage pas à pas de toute la suite de tests en ajoutant ceci dans le code de bootstrap:

register_shutdown_function(function() {
    foreach ($GLOBALS['lastStack'] as $i => $frame) {
        print "{$i}. {$frame['file']} +{$frame['line']} in function {$frame['function']}\n";
    }
});
register_tick_function(function() {
    $GLOBALS['lastStack'] = debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 8);
});
declare(ticks=1);

Si quelqu'un parvient à faire pire que cela, et bloque en quelque sorte stdout également, cette modification devrait fonctionner:

register_shutdown_function(function() {
    $fp = fopen("/tmp/path-to-debugfile.txt", "w");
    foreach ($GLOBALS['lastStack'] as $i => $frame) {
        fwrite($fp, "{$i}. {$frame['file']} +{$frame['line']} in function {$frame['function']}\n");
    }
    fclose($fp);
});
5
LSerni

un vieux fil de celui-ci, mais je suis tombé sur le même problème.

J'ai eu le même problème, rien ne revenant à la console, y compris print, print_r, echo, etc.

résolu en utilisant --stderr en tant que test-runner option. 

4
DevDonkey

Vérifiez que vous n'avez écrit aucune logique dans votre code qui meurt, sans sortie. Par exemple,

<?php

if (!array_key_exists('SERVER_NAME', $_SERVER)) {
    die();
}

C'était exactement mon cas. J'avais émis des hypothèses sur l'environnement qui étaient correctes lors de l'exécution du code via Apache, mais n'étaient pas remplies lors de l'exécution à partir de la CLI et le code ne renvoyait aucune sortie.

PHPUnit a essayé d'inclure le fichier d'amorçage avant de donner la sortie initiale habituelle, mais il est mort pendant le processus d'amorçage, d'où la sortie avec le statut 0 et aucune sortie. 

4
anroots

Si lorsque vous exécutez en ligne de commande une version récente de phpunit comme celle-ci

> php phpunit
or
> ./phpunit
or
> php ./phpunit.phar
or
> ./phpunit.phar

Et vous revenez immédiatement à l'invite sans message, ceci est probablement dû à une configuration "suhosin secutiry" . Phpunit est maintenant un paquet "phar" incluant toutes les bibliothèques. Pour pouvoir exécuter ce fichier lorsque php a activé le module de sécurité suhosin, vous devez d’abord définir ceci 

suhosin.executor.include.whitelist = phar

dans votre fichier php.ini (par exemple, avec debian/ubuntu, vous devrez peut-être éditer le fichier /etc/php5/conf.d/suhosin.ini

3
eldy

Pour moi, le conflit était avec la directive de Xdebug

xdebug.remote_enable=1
1
Yeke

j'ai tout essayé ici, mais rien n'a fonctionné jusqu'à ce que j'ai essayé phpunit --no-configuration simple_test.php. cela m'a finalement donné une sortie, ce qui implique que mon fichier phpunit.xml.dist est cassé. (Je reviendrai et mettrai à jour ceci une fois que je le corrige.)

le contenu de simpletest.php est ci-dessous, mais tout fichier de test devrait fonctionner.

<?php
use PHPUnit\Framework\TestCase;

final class FooTest extends TestCase
{
    public function testFoo()
    {
        $this->assertEquals('x', 'y');
    }
}
1
ryan

Vérifiez si le phpunit que vous utilisez et celui que vous avez installé sont les mêmes:

$ pear list phpunit/phpunit
...
script /path/to/phpunit
...

Essayez d'exécuter exactement ce phpunit avec le chemin complet.

Ensuite, vérifiez votre variable PATH et voyez si le bon répertoire y est. Sinon, corrigez cela.

Si cela ne vous aide pas, utilisez écrire quelque chose dans l'exécutable de phpunit, par exemple "echo 123;" et lancez phpunit. Vérifiez si vous voyez ça.

1
cweiske