Laravel workbench модулен тест

Какъв е начинът да тествам моите пакети в работна среда. Ако напиша единичен тест, тогава никакви класове не се зареждат автоматично. Така че това означава, че:

<?php

use \Mockery as m;

class ExampleTest extends TestCase {

public function tearDown()
{
    m::close();
}

/**
 * A basic functional test example.
 *
 * @return void
 */
public function testShouldReturnValidServer()
{

    $mock = m::mock('MailChimp[sendCurl]');

    MailChimp::listSubscribe( array( 'id' => 'c79a023ff2', 'email_address' => '[email protected]'));

   }
}

води до грешка, която казва, че класът TestCase не е намерен. Когато добавя клас TestCase към автоматичното зареждане в моя composer.json (този в моята папка с пакети), класът е наличен. След това обаче получавам следващата грешка, че „Illuminate\Foundation\Testing\TestCase“ не е наличен и т.н. и т.н. Въпросът ми е какво трябва да заредя автоматично в моя composer.json в моята папка с пакети? Всичко точно като в моя основен composer.json или има някакъв друг начин, който ми липсва.

Знам, че в ръководството пише "

Можете да git init от директорията workbench/[vendor]/[package] и git да избута вашия пакет направо от workbench! Това ще ви позволи удобно да разработите пакета в контекст на приложение, без да бъдете затънали в постоянни команди за актуализиране на композитора.

Аз обаче не разбирам това. Може ли някой да обясни какво се има предвид с това? Между другото съм запознат с git. Просто не разбирам контекста.

РЕДАКТИРАНЕ1 Доколкото разбирам сега, вие изпращате пакета си във вашето хранилище и след това го включвате във вашия основен composer.json като пакет. Просто не виждам как това е полезно при разработването. Надявам се, че разбирам това погрешно.. :)

EDIT2 Сгреших. Дръжте пакета си в работната маса, докато се стабилизира. Точно както Нилс посочи по-долу. Въпросът все още остава. Как да създам среда, в която мога да тествам модул със стартирано приложение. Имам предвид като тестване на модел, където мога да се подигравам на фасадите и т.н. Или правенето на това в работната маса е лоша практика?


person driechel    schedule 04.06.2013    source източник
comment
Ръководството казва точно обратното: Ако държите пакета си в работна среда по време на разработката, не е нужно да използвате композитора. След като стане стабилен и искате да го използвате другаде, ще го добавите към composer.json.   -  person Nils Werner    schedule 04.06.2013
comment
Благодаря. Това е вярно. Тогава къде е изречението git push?   -  person driechel    schedule 04.06.2013
comment
Ами искате вашият пакет (този, който в момента е в workbench) да бъде под контрол на версиите, но отделен от composer. Така че, ако използвате git, можете да направите git push във вашия workspace. Вашият пакет няма да се показва в composer.json, но може да се инсталира във вашата система.   -  person Nils Werner    schedule 04.06.2013
comment
Да добре. Това има смисъл. Така си мислех, че се има предвид, но се обърках. Това означава, че съм добавил ръчно зависимостите в composer.json на пакета. Благодаря   -  person driechel    schedule 04.06.2013
comment
Отговорих на stackoverflow.com/a/25391078/747802 какво работи за мен.   -  person Ademir Mazer Jr - Nuno    schedule 19.08.2014


Отговори (3)


Създадох пакет за тази цел на https://github.com/orchestral/testbench

person crynobone    schedule 12.06.2013
comment
Как бихте провели вашите тестове на работна маса? phpunit от workbench/vendor/package или от корена на laravel? Трябва ли да актуализирате файла laravel phpunit.xml или да добавите такъв към пакета на вашата работна маса? - person brent; 14.01.2014
comment
И аз бих искал малко пояснение - person Steve Bauman; 14.12.2014
comment
Този пакет току-що стана моят нов фаворит. - person Travis B; 07.01.2015
comment
Благодаря ви, това беше абсолютно животоспасяващо. За тези, които се борят с това, внимателно прочетете примера за git и преминете през процеса. - person bmorenate; 08.03.2015

Ако нямате нищо против да обедините резултатите от вашето тестване на работна маса с резултатите от вашето основно приложение, можете просто да добавите допълнителни директории към вашия основен phpunit.xml във вашия корен на laravel по следния начин:

<testsuites>
    <testsuite name="Application Test Suite">
        <directory>./app/tests/phpunit/</directory>
        <directory>./workbench/vendor/packageOne/tests/</directory>
        <directory>./workbench/vendor/packageTwo/tests/</directory>
    </testsuite>
</testsuites>

След това в папката с тестове на вашия пакет поставете вашите phpunit тестове както обикновено, заедно с файла TestCase.php, като коригирате функцията createApplication() да бъде:

<?php

class TestCase extends \Illuminate\Foundation\Testing\TestCase {

public function createApplication()
{
    $unitTesting = true;
    $testEnvironment = 'testing';
    return require './bootstrap/start.php';
}

Уверете се, че вашият пакет composer.json автоматично зарежда файла TestCase.php по следния начин:

"autoload": {
    "classmap": [
        "tests/phpunit/TestCase.php"           
    ]
}

Стартирайте composer dump-autoload -o, за да подравните всичко и след това трябва да можете да стартирате phpunit от вашия корен на laravel и той ще тества както вашето приложение, така и вашите пакети.

person Fixspec    schedule 11.12.2014

Разширете от правилното пространство на имената и трябва да можете да изпълнявате тестове от dir на пакета.

class ExampleTest extends \Illuminate\Foundation\Testing\TestCase {
    ..
}

Вижте също Laravels чисти помощници за тестване в workbench?

person marcanuy    schedule 07.02.2014