Question

我想开发一个包，但我坚持使用Eloquent模型部分。我在工作台中有一个包workbench/vendor/workbench/src/models

我的模特就像

<?php namespace Vendor\Shop\Models;

/**
 * A catalog
 */
class Catalog extends \Eloquent {

    // Define the database
    protected $table = 'catalogs';

    // Mass assignment restriction
    protected $fillable = array('name');

}

?>

我的问题是导入Eloquent命名空间，这是不正确的我猜，因为如果我使用PHPUnit运行UnitTest它只是失败了Class 'Eloquent' not found

这是因为作曲家中的自动加载吗？作曲家文件的摘录：

"require" : {
    "php" : ">=5.3.0",
    "illuminate/support" : "4.0.x",
    "illuminate/database": "4.0.x"
},
"autoload" : {
    "classmap" : [
        "src/controllers",
        "src/models",
        "src/migrations",
        "src/database/seeds"
    ],
    "psr-0": {
        "Vendor\\Shop" : "src/"
    }
},

Answer 1

如果您的测试没有从项目的根目录运行（其中artisan），那么他们很可能不会在测试运行之前引导应用程序。这意味着app/config/app.php中定义的任何别名都没有实际定义。这就是Eloquent，它是指向Illuminate\Database\Eloquent\Model的别名。

你可以在这里做一些事情。

使用名为testbench的包。我没有使用过这个，但我可以告诉它取决于整个laravel/framework存储库。对此我五味杂陈。但基本上这个包运行的设置类似于测试期间Laravel应用程序的设置方式。此程序包可能允许您继续扩展Eloquent，但我无法确认或否认此事。
直接扩展Illuminate\Database\Eloquent\Model。由于您已经依赖illuminate/database存储库，因此这可能会容易得多。这里唯一的缺点是，如果您发布此软件包并且某人已将Eloquent别名替换为他们自己的Eloquent自定义扩展名，那么它将不会应用于您的软件包。因为您的软件包直接扩展了Eloquent而没有使用别名，所以它不够灵活。

最后，这取决于你的包裹的情况。如果它只是由你在内部使用，那么我可能会选择选项2.如果没有，请尝试选项1，如果失败则返回选项2.

希望这有帮助。

Answer 2

正如Jason Lewis在评论中提到的，这里的主要问题是phpunit是bootstrapping的地方。如果您使用全新安装的Laravel在workbench文件夹中开发Laravel软件包，可以非常安全地假设您的软件包不是框架无关的，并且完全依赖于Laravel。

因此，它不是必要的＆＃34;单独测试在包目录中执行的单元测试。也就是说，假设我们并不担心某种CI过程被搞砸了，但可能还有一些解决方法。我将对此进行更多研究。

所以我选择了第三种选择。只需像往常一样从TestCase扩展您的软件包测试。

class MyAwesomeTest extends TestCase {}

然后在命令行中，cd进入父Laravel项目的根目录，并以workbench目录作为参数运行phpunit。

phpunit workbench/vender/my-package/tests/

这将使用父级Laravel的引导程序执行所有包的单元测试，从而使您可以访问所有令人敬畏的Laravel单元测试，帮助您习惯。

Laravel 4，工作台包中的模型，Eloquent未找到

2 个答案: