【问题标题】:Laravels neat testing helpers in workbench?Laravel 在工作台中整洁的测试助手?
【发布时间】:2014-03-05 05:13:51
【问题描述】:

查看laravel testing documentation,您会了解我喜欢在工作台中使用的所有很酷的助手。

很遗憾,我做不到。

Illuminate\Foundation\Testing\TestCase 从包目录运行我的测试时似乎不可用,因此我无法扩展它。

<?php namespace Acme\Foo;

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

    /**
     * Creates the application.
     *
     * @return \Symfony\Component\HttpKernel\HttpKernelInterface
     */
    public function createApplication()
    {
        $unitTesting = true;

        $testEnvironment = 'testing';

        return require __DIR__.'/../../../../bootstrap/start.php';
    }

}

PHP Fatal error:  Class 'Illuminate\Foundation\Testing\TestCase' not found in 
/Applications/MAMP/htdocs/Webseiten/acme/workbench/acme/foo/tests/TestCase.php on line 3

我认为这不是正确的方法,无论如何都应该这样做......

我已经找到了orchestral/testbench,但我不确定使用它是否是个好主意。它似乎需要整个 laravel 框架,这对我来说没有意义吗? (一个包应该扩展一个 laravel 安装而不是第二次添加框架!?)

【问题讨论】:

  • 它添加了整个框架,因为如果你将包推送到 github 并在 travis-ci 上运行它,那么它就会丢失。
  • 所以将 "laravel/framework": "4.1.*" 添加到包 composer.json "require-dev" 将是一个好习惯吗?
  • 添加它是为了确保当你需要 2.0 时,它会加载 laravel 4.0,当你加载 2.1 时,它会加载 laravel 4.1 等等。它有什么不同吗?可能仅适用于仅在工作台上使用它的人,但在一个应用程序中再次加载两个作曲家供应商仍然是一个坏主意。在这个阶段,我并没有真正专注于支持导致 github.com/orchestral/testbench#working-with-workbenchgithub.com/orchestral/testbench/issues/29 等问题的工作台
  • 好的,我明白了。所以如果我只是"require-dev" "laravel/framework": "4.1.*" 它可能不会工作。 testbench是否可以解决这些问题,但目前在 4.1 上表现不佳...有什么好的选择吗?使用 travis-ci 测试开发 laravel 包的最佳方法是什么——不要管工作台,做完全不同的事情?
  • 我的建议是在了解包开发的早期阶段使用工作台。一旦你熟悉了它,就将它移出并作为一个独立的包继续工作,原因有很多。

标签: laravel laravel-4 phpunit workbench


【解决方案1】:

我就是这么干的,

首先,更改工作台目录中的phpunit.xml 内容。您将“引导”属性部分,将其从 vendor/autoload.php 更改为 ../../../bootstrap/autoload.php

然后尝试在您的工作台目录上运行phpunit

【讨论】:

  • 或者,您可以在命令行上传递引导选项(如果您不想更改配置文件):phpunit --bootstrap=../../../bootstrap/autoload.php
  • 这太好了,两个答案都对我有很大帮助,非常感谢!
【解决方案2】:

对我来说,由于工作台的设置方式,测试用例只能从 PHPUnit_Framework_TestCase 扩展。所以我从 app 文件夹而不是包文件夹运行测试用例。

我选择第二个选项,因为 testbench 很大程度上取决于特定的 Laravel 版本,并且设置起来似乎有点繁重。我所做的是将主应用程序下的 phpunit.xml 配置为将包测试文件夹包含为测试套件:

<testsuite name="MyPack">
    <directory>./workbench/winponta/mypack/tests/</directory>
</testsuite>

然后运行:

$ phpunit --testsuite=MyPack

使用这种方法,我们仍然可以从 \Illuminate\Foundation\Testing\TestCase 扩展。

我在http://ngo-hung.com/blog/2014/04/16/laravel-unit-testing-in-workbench-note找到了这个解决方案

【讨论】:

  • 是的,这是一个很好的解决方案。只有当您想要进行某种 CI 时才会出现问题。 (例如特拉维斯,我就是这种情况)谢谢你的回答:-)
  • 好吧,我在这个 Laravel 项目中仍然没有使用 CI,所以不必考虑它。欢迎您。
【解决方案3】:

删除

命名空间 Acme\Foo;

应该修复它。然后你可以从包目录运行测试。还要确保在包目录中运行 composer dump-autoload 或从主应用程序目录运行 php artisan dump-autoload

更新我能够在干净的 Laravel 4.1 安装中复制错误并按照以下步骤修复它,而无需安装额外的包:

1 - 在主 laravel 根目录 composer.json 中安装 PHPUnit(不是工作台包 composer.json 文件)

"require-dev": {
     "phpunit/phpunit": "3.7.*"
},

2 - 在主 laravel 根目录中运行 composer update

3 - 在您的测试类中使用完全限定名称(命名空间以 为前缀)

<?php
class SomeTest extends \Illuminate\Foundation\Testing\TestCase {
   public function createApplication()
   {
       $unitTesting = true;
       $testEnvironment = 'testing';
       return require __DIR__.'/../../../../bootstrap/start.php';
   }
   public function testSomething()
   {
       $this->assertTrue(true);
   }
}

4 - 要运行工作台包测试,请转到包目录并运行 main phpunit

# in workbench/package/vendor dir run
../../../vendor/bin/phpunit

5 - 输出绿色标志识别 laravel 应用第三方包

marcanuy@bolso-server:~/public_html/pkgtesting/workbench/my/pack$ ../../../vendor/bin/phpunit --debug
PHPUnit 3.7.31 by Sebastian Bergmann.

Configuration read from /home/marcanuy/public_html/pkgtesting/workbench/my/pack/phpunit.xml


Starting test 'SomeTest::testSomething'.
.

Time: 64 ms, Memory: 6.25Mb

OK (1 test, 1 assertion)

【讨论】:

  • 你以前做过吗?对我来说,这不会改变任何东西:-/(+ 这是一个干净的 laravel 安装)
  • 是的,最近我一直在努力解决类似的问题,试图在不引入新包的情况下测试一个包,我在这里工作正常:github.com/marcanuy/popularity/blob/master/tests/StatsTest.php 然后我从包目录运行我的测试,比如 ../ ../../vendor/bin/phpunit
  • 这很奇怪,因为如果我像您在测试中所做的那样添加命名空间,我会收到与您收到的相同的错误,删除它后工作正常,您是否运行了 dump-autoloads?
  • 是的,我确实从我的应用程序的根目录运行了php artisan dump-autoload。它甚至提到它考虑了我的工作台。我会看看你的存储库。也许这会有所帮助。无论如何,如果我不想使用 travis-ci,这将不起作用,对吧?
  • 不确定,因为我还没有将 travis-ci 与 Laravel 包一起使用,但可能可以设置自定义脚本。
猜你喜欢
  • 1970-01-01
  • 2013-05-30
  • 1970-01-01
  • 2014-07-08
  • 1970-01-01
  • 2018-07-03
  • 2014-09-19
  • 2023-03-16
  • 1970-01-01
相关资源
最近更新 更多