Модульное тестирование с элементами, которым необходимо отправлять заголовки

Ну, ваш менеджер сеансов в основном сломан по дизайну. Чтобы иметь возможность что-то протестировать, необходимо изолировать это от побочных эффектов. К сожалению, PHP устроен таким образом, что поощряет либеральное использование глобального состояния (echo, header, exit, session_start и т. д. и т. д.).

Лучшее, что вы можете сделать, это изолировать побочные эффекты в компоненте, который можно поменять местами во время выполнения. Таким образом, ваши тесты могут использовать фиктивные объекты, в то время как живой код использует адаптеры, которые имеют реальные побочные эффекты. Вы обнаружите, что это не очень хорошо работает с синглтонами, которые, я полагаю, вы используете. Поэтому вам придется использовать какой-то другой механизм для распространения общих объектов в вашем коде. Вы можете начать со статического реестра, но есть и лучшие решения, если вы не против немного поучиться.

Если вы не можете этого сделать, у вас всегда есть возможность написать интеграционные тесты. Например. используйте эквивалент PHPUnit WebTestCase.

Создайте загрузочный файл для phpunit, который вызывает:

session_start();

Затем запустите phpunit следующим образом:

phpunit --bootstrap pathToBootstrap.php --anotherSwitch /your/test/path/

Файл начальной загрузки вызывается перед всем остальным, поэтому заголовок не был отправлен, и все должно работать нормально.

phpUnit выводит вывод по мере выполнения тестов, что приводит к тому, что headers_sent() возвращает true даже в вашем первом тесте.

Чтобы решить эту проблему для всего набора тестов, вам просто нужно использовать ob_start() в вашем сценарии установки.

Например, предположим, что у вас есть файл с именем AllTests.php, который первым загружается phpUnit. Этот сценарий может выглядеть следующим образом:

<?php

ob_start();

require_once 'YourFramework/AllTests.php';

class AllTests {
    public static function suite() {
        $suite = new PHPUnit_Framework_TestSuite('YourFramework');
        $suite->addTest(YourFramework_AllTests::suite());
        return $suite;
    }
}

У меня была такая же проблема, и я решил ее, вызвав phpunit с флагом --stderr следующим образом:

phpunit --stderr /path/to/your/test

Надеюсь, это поможет кому-то!

Я думаю, что «правильным» решением является создание очень простого класса (настолько простого, что его не нужно тестировать), который является оболочкой для функций PHP, связанных с сеансом, и использовать его вместо прямого вызова session_start() и т. д.

В тесте передайте фиктивный объект вместо реального, непроверяемого класса сеанса с отслеживанием состояния.

private function __construct(SessionWrapper $wrapper)
{
   if (!$wrapper->headers_sent())
   {
      $wrapper->session_start();
      $this->session_id = $wrapper->session_id();
   }
}

Мне интересно, почему никто не указал опцию XDebug:

/**
 * @runInSeparateProcess
 * @requires extension xdebug
 */
public function testGivenHeaderIsIncludedIntoResponse()
{
    $customHeaderName = 'foo';
    $customHeaderValue = 'bar';

    // Here execute the code which is supposed to set headers
    // ...

    $expectedHeader = $customHeaderName . ': ' . $customHeaderValue;
    $headers = xdebug_get_headers();

    $this->assertContains($expectedHeader, $headers);
}

Разве вы не можете использовать буферизацию вывода перед запуском теста? Если вы буферизуете все, что выводится, у вас не должно возникнуть проблем с настройкой каких-либо заголовков, поскольку в этот момент вывод еще не был отправлен клиенту.

Даже если OB используется где-то внутри ваших классов, он является стекируемым, и OB не должен влиять на то, что происходит внутри.

Насколько я знаю, Zend Framework использует ту же буферизацию вывода для своих тестов пакета Zend_Session. Вы можете взглянуть на их тестовые примеры, чтобы начать.

Создание загрузочного файла, указанное 4 постами назад, кажется самым чистым способом обойти это.

Часто с PHP нам приходится поддерживать и пытаться добавить какую-то инженерную дисциплину к устаревшим проектам, которые ужасно собраны. У нас нет времени (или полномочий), чтобы выкинуть всю кучу мусора и начать заново, поэтому первый ответ troelskn не всегда возможен как путь вперед. (Если бы мы могли вернуться к исходному дизайну, тогда мы могли бы вообще отказаться от PHP и использовать что-то более современное, такое как ruby ​​или python, вместо того, чтобы помогать увековечивать этот COBOL в мире веб-разработки.)

Если вы пытаетесь написать модульные тесты для модулей, которые используют session_start или setcookie в них, то запуск сеанса в файле boostrap решит эти проблемы.

Поскольку я сейчас тестирую свой бутстрап (да, я знаю, что большинство из вас этого не делает), я столкнулся с той же проблемой (и header(), и session_start()). Решение, которое я нашел, довольно простое: в вашем юниттест-бутстрапе определите константу и просто проверьте ее перед отправкой заголовка или запуском сеанса:

// phpunit_bootstrap.php
define('UNITTEST_RUNNING', true);

// bootstrap.php (application bootstrap)
defined('UNITTEST_RUNNING') || define('UNITTEST_RUNNING', false);
.....
if(UNITTEST_RUNNING===false){
    session_start();
}

Я согласен, что это не идеально по дизайну, но я тестирую существующее приложение, переписывая большие части не желательно. Я также использую ту же логику для тестирования частных методов, используя магические методы __call() и __set().

public function __set($name, $value){
    if(UNITTEST_RUNNING===true){
       $name='_' . $name;
       $this->$name=$value;
    }
    throw new Exception('__set() can only be used when unittesting!');
 }

Кажется, вам нужно внедрить сеанс, чтобы вы могли протестировать свой код. Лучший вариант, который я использовал, — это Aura.Auth для процесса аутентификации и использование NullSession и NullSegment для тестирования.

Тестирование Aura с нулевыми сеансами

Фреймворк Aura прекрасно написан, и вы можете использовать Aura.Auth самостоятельно без каких-либо других зависимостей от фреймворка Aura.