Phpunit: problème "en-têtes déjà envoyés" dans les tests isolés lors de l'exécution avec PHAR

Créé le 18 mars 2014  ·  26Commentaires  ·  Source: sebastianbergmann/phpunit

J'ai du code qui émet des en-têtes sur lesquels je n'ai aucun contrôle, tout comme #720 . Comme suggéré, j'ai exécuté le test dans un processus séparé, et cela a fonctionné lors de l'exécution avec phpunit installé par composer dans le répertoire vendor/bin.

MAIS, cela ne fonctionne pas lorsqu'il est exécuté avec une archive phpunit PHAR, les "en-têtes" sont toujours envoyés, après quelques recherches, j'ai trouvé que c'est la première ligne shebang "#!/usr/bin/env php" dans le stup.php qui cause ce problème.

Si le PHAR est chargé en tant que bibliothèque par 'require', la ligne shebang est absolument inutile.

OU, corrigez cela en appelant 'ob_start()' dans https://github.com/sebastianbergmann/phpunit/blob/master/src/Util/PHP/Template/TestCaseMethod.tpl.dist juste avant le chargement de l'archive phar , mais ce n'est pas ainsi qu'il faut procéder.

Commentaire le plus utile

J'obtiens ce problème si je n'utilise pas --stderr comme paramètre lors de l'exécution de mes tests...

Tous les 26 commentaires

@sebastianbergmann a-t-il une chance d'obtenir un correctif pour cela ? Il empêche la suite de tests Symfony2 de passer lors de l'utilisation du phar

Je ne sais pas quelle est la bonne solution. Supprimer la ligne shebang du talon PHAR rendrait le PHAR inutilisable, n'est-ce pas?

@fabpot Avez-vous une idée de comment résoudre ce problème ?

le supprimer rendrait en effet impossible l'exécution directe phpunit.phar , nécessitant l'utilisation php phpunit.phar .

Alors peut-être que l'utilisation du tampon de sortie autour de l'inclusion phar, comme suggéré par @techlivezheng , pourrait faire l'affaire.
actuellement, le tampon de sortie n'est démarré qu'après avoir demandé le phar

@sebastianbergmann le correctif sera-t-il publié en tant que version 4.0.19, ou sera-t-il disponible uniquement en 4.1 ou 4.2 ?

Ce sera en 4.0.19.

Le correctif sera également dans PHPUnit 3.7.37.

quand comptez-vous le sortir ? C'est pour nous laisser décider comment nous gérons la réparation de nos versions de Travis (exécuter un phpunit --self-update pour obtenir le nouveau phar 4.0 ou installer à partir de la source avec composer)

PHPUnit 3.7.37 et PHPUnit 4.0.19 ont été publiés.

Salut les gars.

J'ai phpUnit 4.4.1 et le problème persiste toujours. J'essaie à la fois le bin phar et composer (processus séparés et non), mais le problème persiste.

Si séparé, j'obtiens l'exception suivante :
PHP Fatal error: Uncaught exception 'Exception' with message 'Serialization of 'SplFileInfo' is not allowed' in phar:///usr/local/bin/phpunit/phpunit/Util/GlobalState.php:211

Si vous utilisez le chutier du composeur :

Call stack:
Exception: Serialization of 'SplFileInfo' is not allowed in /path/to/project/vendor/phpunit/phpunit/src/Util/GlobalState.php on line 211

  0.0004     641608   1. {main}() /path/to/project/vendor/phpunit/phpunit/phpunit:0
  0.0161    1666672   2. PHPUnit_TextUI_Command::main() /path/to/project/vendor/phpunit/phpunit/phpunit:62
  0.0161    1667712   3. PHPUnit_TextUI_Command->run() /path/to/project/vendor/phpunit/phpunit/src/TextUI/Command.php:138
  0.4945   14352368   4. PHPUnit_TextUI_TestRunner->doRun() /path/to/project/vendor/phpunit/phpunit/src/TextUI/Command.php:186
  2.0006   17549968   5. PHPUnit_Framework_TestSuite->run() /path/to/project/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:423
  4.7326   22223080   6. PHPUnit_Framework_TestSuite->run() /path/to/project/vendor/phpunit/phpunit/src/Framework/TestSuite.php:751
  9.4326   24608496   7. PHPUnit_Framework_TestSuite->run() /path/to/project/vendor/phpunit/phpunit/src/Framework/TestSuite.php:751
  9.4356   24613072   8. PHPUnit_Framework_TestCase->run() /path/to/project/vendor/phpunit/phpunit/src/Framework/TestSuite.php:751
  9.4394   24695088   9. PHPUnit_Util_GlobalState::getGlobalsAsString() /path/to/project/vendor/phpunit/phpunit/src/Framework/TestCase.php:651
  9.4405   24705776  10. PHPUnit_Util_GlobalState::exportVariable() /path/to/project/vendor/phpunit/phpunit/src/Util/GlobalState.php:185
  9.4405   24705856  11. serialize() /path/to/project/vendor/phpunit/phpunit/src/Util/GlobalState.php:211

Sinon, l'erreur d'en-tête :
Cannot modify header information - headers already sent by (output started at phar:///usr/local/bin/phpunit/phpunit/Util/Printer.php:172)

Dans mon code, j'utilise la session, mais pas les en-têtes si cela compte.

Quelqu'un a-t-il une idée de comment puis-je le réparer ou l'éviter?

PS En raison de ce commentaire , il semble que quelque chose ne va pas avec mon installation de phpUnit.

PHPUnit 4.5.0 - Impossible de modifier les informations d'en-tête - en-têtes déjà envoyés par (la sortie a commencé à phar:///usr/local/bin/phpunit/phpunit/Util/Printer.php:137)

Je peux également confirmer que PHPUnit 4.5.1 produit Uncaught PHP Exception PHPUnit_Framework_Error_Warning: "Cannot modify header information - headers already sent by (output started at /workspaces/app/tests/vendor/phpunit/phpunit/src/Util/Printer.php:139)"

De plus, le dernier PHPunit 4.8.6 génère la même erreur

Cannot modify header information - headers already sent by (output started at phar:///usr/local/zend//tests/phpunit-4.8.5.phar/phar/phpunit/Util/Printer.php:133)

PHPUnit 5.2.0 par Sebastian Bergmann et ses contributeurs.

ErrorException : Impossible de modifier les informations d'en-tête - les en-têtes ont déjà été envoyés par (la sortie a commencé à phar:///usr/bin/phpunit/phpunit/Util/Printer.php:134)

Ce n'est pas parce que le message d'erreur contient "Impossible de modifier les informations d'en-tête" qu'il s'agit du même problème.

Eh bien, mon test n'utilise rien en rapport avec les en-têtes. De plus, cela fonctionnait avec la version précédente de php, le test n'a pas changé, mais maintenant, il génère cette erreur. J'ai donc pensé que cela pouvait être lié.

Fonctionne bien avec un seul test, par exemple --filter=mytest

J'ai aussi le même problème :

PHPUnit 5.5.4 by Sebastian Bergmann and contributors.
Starting test 'ExampleTest::testBasicExample'.
Cannot modify header information - headers already sent by (output started at ../vendor/phpunit/phpunit/src/Util/Printer.php:134)

J'obtiens ce problème si je n'utilise pas --stderr comme paramètre lors de l'exécution de mes tests...

J'ai le même problème que celui décrit ici: Maatwebsite/Laravel-Excel/issues/511

ce problème peut être contourné en utilisant une imprimante personnalisée dans laquelle vous définissez explicitement `$out' sur stdout

J'ai rencontré ce problème lorsque mon contrôleur a été redirigé vers une page de connexion.

Corrigé en utilisant la solution @victorbstan :

bin/phpunit --stderr

J'ai rencontré ce problème lors de l'exécution de tests Codeception dans le conteneur docker throw PHPStorm .
exécutez codecept directement dans le conteneur Docker aux mêmes tests et config évitez ce problème.

Yii2 Alert() widget ne peut pas démarrer la session

@dynasource STDOUT sera fermé ici
https://github.com/sebastianbergmann/phpunit/blob/e6e7085fbbd2e25f4ca128ac30c1b0d3dd4ef827/src/Util/Printer.php#L73 -L78
ce sera redéfini aussi

/**
 * For avoid set headers before session start
 * Class PhpStorm_Codeception_ReportPrinter_Redefine
 */
class PhpStorm_Codeception_ReportPrinter_Redefine extends PHPUnit_TextUI_ResultPrinter
{
    /**
     * <strong i="10">@inheritDoc</strong>
     */
    public function __construct(
        $out = null,
        $verbose = false,
        $colors = self::COLOR_DEFAULT,
        $debug = false,
        $numberOfColumns = 80,
        $reverse = false
    ) {
        parent::__construct(STDOUT, $verbose, $colors, $debug, $numberOfColumns, $reverse);
    }

    /**
     * Flush buffer and close output if it's not to a STDOUT stream
     */
    public function flush()
    {
        if ($this->out != STDOUT) {
            parent::flush();
        }
    }
}

PHPUnit 8.5.0 par Sebastian Bergmann et ses contributeurs.
Erreur fatale PHP : Uncaught Impossible de modifier les informations d'en-tête - les en-têtes ont déjà été envoyés par (la sortie a commencé à phar:///usr/local/bin/phpunit/phpunit/Util/Printer.php:99)

ah désolé .. --stderr résout mon problème

J'ai rencontré ce problème lorsque mon contrôleur a été redirigé vers une page de connexion.

Corrigé en utilisant la solution @victorbstan :

bin/phpunit --stderr

J'ai eu le même problème lors du test d'une demande de téléchargement de fichier.
Fonctionne pour moi aussi après avoir ajouté le paramètre.
Étonnante!

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

TiMESPLiNTER picture TiMESPLiNTER  ·  3Commentaires

stemis picture stemis  ·  3Commentaires

sebastianbergmann picture sebastianbergmann  ·  4Commentaires

greg0ire picture greg0ire  ·  4Commentaires

rentalhost picture rentalhost  ·  4Commentaires