感谢他们的提问。以我的拙见,恕我直言,Truly Theys!,错误消息发布:
错误:在 null 上调用成员函数 connection()
在我看来可能是由以下调用链中的隐藏数据库访问层引起的:
Event::inRandomOrder()->select('id')->whereNotNull('logo')->first()
在我看来,当调用数据提供者时,隐藏的数据库访问层之类的东西不工作(或未准备好)。
有什么办法吗?
根据我对数据提供者摘录上下文中的错误消息的印象,我认为一个潜在的解决方案可能是在调用链之前设置(配置)数据库访问层。
在我看来,配置是整个测试装置的一部分。
当看到此错误消息并假设配置是夹具的一部分时,解决方案是在执行数据提供程序时设置夹具。
根据 Dataprovider can [sic] get connection from setUp 标准,setUp 和 setUpBeforeClass 钩子不适用于数据提供者方法。
因此,一个额外的解决方案可能是使用 bootstrap-file Phpunit 设置。引导是在运行任何测试用例之前完成的,绑定到全局静态状态的数据提供者会发现它已配置。
我会考虑什么作为替代解决方案?
根据我自己的经验 - 他们的里程可能会有所不同 - 在我看来,这通常是最直接的,并且通常足以决定首先在 Phpunit 中使用数据提供程序时在没有数据库连接的情况下进行测试。
当有一个更大的测试数据集时,数据提供者可以很容易地从作为测试套件一部分的夹具文件中获取,并且文件系统通常在运行时至少可用于读取访问测试套件。
然后任何数据提供者只返回简单的测试参数,而不使用其他昂贵的数据层和设置。
最近版本的 Phpunit 也会打乱所提供数据的顺序,就像测试运行器对测试方法的执行顺序所做的那样。
另请参阅此 answer to "Mocking PDO with phpunit" 中 2020 年 5 月的编辑。
这并不意味着没有特定的测试需要数据库适配器和通过网络提供服务的测试数据库(通常称为集成测试或数据库测试 em>)。
需要使用数据库适配器运行的测试然后在它自己的测试套件中完成,该套件可以更专门地运行以测试与数据库适配器的集成以及与数据库系统的连接。
之所以进行划分是因为使用数据库连接的测试通常要昂贵得多 - 有多种方式:配置/设置、编写/维护测试和数据,最后但并非最不重要的是运行测试 - 这样他们很容易成为快速反馈循环中的阻碍者,因此他们只执行专门针对不同特定开发目标(例如夜间)的反馈。