Laravel 在工作台中整洁的测试助手？

Posted 2023-03-15

【中文标题】Laravel 在工作台中整洁的测试助手？

【英文标题】：Laravels neat testing helpers in workbench?

【发布时间】：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-workbench 和 github.com/orchestral/testbench/issues/29 等问题的工作台

好的，我明白了。所以如果我只是"require-dev" "laravel/framework": "4.1.*" 它可能不会工作。 testbench是否可以解决这些问题，但目前在 4.1 上表现不佳...有什么好的选择吗？使用 travis-ci 测试开发 laravel 包的最佳方法是什么——不要管工作台，做完全不同的事情？

我的建议是在了解包开发的早期阶段使用工作台。一旦你熟悉了它，就将它移出并作为一个独立的包继续工作，原因有很多。

【参考方案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 包一起使用，但可能可以设置自定义脚本。