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.
@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!
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...