Вероятность довольно высока, что невозможно помочь мне, не видя эту кодовую базу, в которой я нахожусь, но я бы хотел спросить здесь на случай, если кто-то сделал что-то подобное
Ниже я более подробно расскажу о ситуации, в которой я нахожусь, но основной вопрос, который я задаю: кто-нибудь должен был писать тесты для унаследованной кодовой базы, которая использует Laravel в качестве зависимости, и могли ли вы использовать Laravel? TestCase или вам приходилось играть свою собственную среду тестирования?
Я работаю в более чем 15-летнем устаревшем php-приложении … Около года назад они начали писать свои новые API в Laravel. Устаревшее приложение включает в себя приложение Laravel в качестве зависимости. Итак, что происходит, через htaccess
переписать правило, запросы собираются api/v2
нажмите файл индекса, который загружает приложение Laravel. Этот индексный файл включает в себя init.inc.php
который выполняет тонкую настройку для унаследованного приложения, затем, когда приложение Laravel загружается, оно фактически загружает пользовательский класс, который расширяет Laravel. Illuminate\Foundation\Application
, Это происходит потому, что существует множество устаревших конфигураций, которые передаются Zend_Config
и затем устанавливает каталог хранилища так, чтобы он указывал на устаревшее приложение вместо приложения laravel.
Приложение Laravel — это частный упаковщик, который во время разработки получает ссылку на локальную копию репозитория. Во время производства это просто пакет поставщика.
Я пытаюсь настроить тесты для этой чертовой вещи … и это не очень хорошо, лол
Я очень надеялся, что смогу иметь набор тестов в самом приложении Laravel, но не похоже, что я смогу это сделать, потому что поток начальной загрузки создается при условии, что унаследованное приложение выполняет все свои настроить до раскрутки Laravel, и, конечно же, приложение Laravel также зависит от старого приложения.
Итак, на чем я пытался остановиться — это настроить тесты внутри унаследованного приложения и запустить стандартную последовательность загрузки, а затем запустить Laravel. Я могу заставить это работать с BaseTestCase
класс расширяет PHPUnit\Framework\TestCase
и я могу получить свои экземпляры Eloquent внутри теста, я могу поразить конечные точки с помощью Guzzle и утверждать ответы и т. д. … все работает нормально work
Проблема в том, что на данный момент у меня нет простого способа проверить что-либо изолированно, так что прикосновение к базе данных пока является моим первым методом перехода. Однако у меня также нет простого способа заполнения тестовых данных, и у меня нет простого способа обернуть свои тесты в транзакции, которые откатываются после каждого теста. (Возможно, мне придется идти по этому пути честно, но, похоже, это может привести к большой работе). Что было бы удивительно, если бы я мог просто использовать Illuminate\Foundation\Testing\TestCase
тогда у меня были бы все вкусности Laravel, такие как отсутствие необходимости работать напрямую с Guzzle, но также такие черты, как DatabaseTransactions
а также WithoutEvents
или же WithoutMiddleware
и т.п.
Что-то не так, хотя. Когда я пытаюсь расширить Laravel TestCase, я получаю странные ошибки, такие как Argument 1 passed to Illuminate\Database\Eloquent\Model::setEventDispatcher() must implement interface Illuminate\Contracts\Events\Dispatcher, null given,
Погружение через некоторый исходный код выглядит TestCase
проверяет, является ли app
был создан, и если не вызывает реферат createApplication()
метод, который определен на моем обычае TestCase
но ошибка, которую я получаю, говорит мне, что $app['events']
является null
, Тьфу, и, конечно, я не могу заставить Xdebug работать в их среде, так что я не могу должным образом пройти и посмотреть, что именно происходит.
По сути, моя главная цель сейчас — выяснить, как заставить отладку работать с их настройкой, чтобы я мог на самом деле шагать по коду, но я решил, что я бы поставил здесь вопрос на StackOverflow на случай, если у кого-то будет какой-либо совет. Все, что приближает меня к возможности использовать Laravel TestCase, было бы поразительным ощущением прямо сейчас.
Я знаю, что это длинный выстрел, но кто-нибудь когда-нибудь пробовал что-то подобное раньше? Удалось ли вам заставить тестовый набор Laravel работать в унаследованном приложении?
редактировать
Вот что мой createApplication
override выглядит как после удаления реальных путей с поддельными:
public function createApplication()
{
@set_include_path(implode(PATH_SEPARATOR, array(
dirname(__FILE__) . "/../../www-root/core",
dirname(__FILE__) . "/../../www-root/core/includes",
dirname(__FILE__) . "/../../www-root/core/library",
dirname(__FILE__) . "/../../www-root/core/library/vendor",
get_include_path(),
)));
require_once("init.inc.php");
$this->app = require_once 'private-packagist-package/src/bootstrap/app.php';
$kernel = $this->app->make(\Illuminate\Contracts\Http\Kernel::class);
$response = $kernel->handle(
$request = \Illuminate\Http\Request::capture()
);
$response->send();
$kernel->terminate($request, $response);
}
Тот же самый код работает в моем базовом тестовом примере, где я просто расширяю тестовый пример PHPUnit.
Задача ещё не решена.
Других решений пока нет …