Question

我们有一堆迁移（200多个），其中大多数用于更改数据库中的数据，并且会影响我们的测试。例如，我们有这样的迁移

 public function up()
    {
        $deleteId = DB::table('lookups')
            ->where('code', '=', 'VI')
            ->where('type', '=', 'country')
            ->where('value', '=', 'U.S. Virgin Islands')
            ->first(['id'])->id;

           DB::table('lookups')
                ->where('id', '=', $deleteId ?? 0)
                ->update(['deleted_at' => Carbon::now()->toDateTimeLocalString()]);
    }

如您所见，如果我们在测试环境中运行它，将抛出错误。因为该记录在测试环境中不存在。（我们为此目的使用了造假者）。我的问题是，我们应该避免一些迁移吗？什么是最佳解决方案？

Answer 1

有趣的问题。我将在回答中做出一些假设，因此请复查它们，并让我知道是否有错误。

您是开发团队的一部分。
在客户环境中，如果在运行迁移时记录不存在，那么这是环境中的错误。
您没有在此测试中明确测试此迁移。

好吧，首先我的脑海里响起了一些警钟。本质上，您是在说您的测试环境与客户环境不匹配。当然，这不一定是问题，但是请确保您的测试环境足以代表客户环境，以使测试有意义。

在理想情况下，我将通过确保您的虚假环境具有迁移所需的记录来避免该错误。这样，您还可以在迁移过程中进行迁移。

您是否提供了伪造的数据库，例如用于测试的内存数据库？如果是这样，只需在数据库启动时添加记录，即可运行迁移。

您是否正在模拟对数据库的调用？如果是这样，您是否尝试过模拟对该函数的调用，并使其实质上成为无操作？

我们是否还应该使用仅用于更改测试中数据库中数据的那些迁移？

1 个答案: