0

我想开发一个包，但被 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/"
    }
},
4

2 回答 2

2

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

你可以在这里做几件事。

  1. 使用一个名为testbench的包。我没有使用过它，但据我所知，它取决于整个laravel/framework存储库。对此我五味杂陈。但本质上，这个包运行的设置类似于你的 Laravel 应用程序在测试期间的设置。这个包可能允许你继续扩展Eloquent，尽管我不能确认或否认这一点。

  2. Illuminate\Database\Eloquent\Model直接展开。这可能要容易得多，因为您已经依赖于illuminate/database存储库。这里唯一的缺点是，如果你发布了这个包并且有人Eloquent用他们自己的 Eloquent 自定义扩展替换了别名，那么它将不会应用于你的包。因为你的包直接扩展了 Eloquent 而不是使用别名，所以它没有那么灵活。

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

希望这会有所帮助。

于 2013-07-08T16:22:58.800 回答
0

正如 Jason Lewis 在评论中提到的，这里的主要问题是 phpunit 在哪里进行引导。如果你正在workbench使用全新安装的 Laravel 在文件夹中开发你的 Laravel 包，那么可以假设你的包与框架无关，并且完全依赖于 Laravel。

因此，在包目录中专门从其他所有内容执行单元测试并不是“必要的”。也就是说，假设我们不担心某种 CI 过程会搞砸，但可能有一些解决方法。我将对此进行更多研究。

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

class MyAwesomeTest extends TestCase {}

然后在命令行中，cd进入父 Laravel 项目的根目录并使用你的工作台目录作为参数运行 phpunit。

phpunit workbench/vender/my-package/tests/

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

于 2014-03-22T09:35:54.807 回答