Laravel 测试入门
发布时间:作者: Eric L. Barnes
构建经过良好测试并具有高测试自动化覆盖率的 Laravel 项目可能需要大量工作。同时,对于没有专门的 QA 团队的小型团队来说,这也是现实中唯一能够自信地持续添加新功能的方法,而不会造成不断破坏现有功能的风险。在这篇文章中,我想介绍 Laravel 项目的测试,涵盖所有方面。
我们的团队正在构建一个 测试管理 工具,因此我们的目标自然是要拥有高测试覆盖率和高质量的发布(“鞋匠的鞋总是最差的”这句话在这里不适用)。我们的用户通常是软件测试人员,因此他们在软件质量和可用性方面对我们寄予厚望(他们善于发现并解决最小的问题)。因此,我们在测试策略方面投入了大量工作,下面我将概述我们如何测试 Laravel 项目。
使用 PHPUnit 进行后端测试
在 Laravel 中开始测试最简单的方法是使用 PHPUnit 构建单元测试。Laravel 已经预先配置好以便开箱即用地运行单元测试,并且在设置和运行测试方面有 很棒的文档。不过,在你开始之前,我建议你思考一下在后端代码中究竟可以测试什么,以及应该测试什么,因为你可以构建不同类型的测试。我们使用 PHPUnit 来实现不同的、独立的测试套件,这些测试套件专注于代码的不同方面。
-
助手和库的单元测试:完全独立于应用程序其他部分的代码可以很容易地在小型、独立的单元测试中进行测试。想想格式化数据的助手,例如日期/时间、转换颜色值,或者生成特定导出格式的库。
-
队列作业和命令:后台作业和命令通常对数据执行重要操作,例如存档不再需要的旧条目,或生成计划的报告。因此,对作业和命令进行自动化测试至关重要,因此你应该拥有独立的测试套件。
-
控制器和模型:应用程序的 API、模型和视图的测试很可能成为你最大的测试套件之一。Laravel 使得构建快速 API 和控制器测试来覆盖所有内容变得很容易。
-
数据库迁移:如果你在改进应用程序并随时间添加新功能,你通常需要更改数据库模式,并可能迁移现有数据。如果没有考虑所有边缘情况的可靠的自动化测试,这可能很难测试,因此确保花时间构建这些测试。
好消息是,构建这些测试通常也会使开发变得容易得多。例如,我们的团队通常在构建后端测试以先开发和尝试后端功能,然后再在后面的步骤中添加任何 UI。如果不先编写这些测试,就很难构建新功能。我们自己使用 Testmo 进行 测试自动化报告,以便我们能够跟踪所有后端测试。
使用 Dusk 进行 UI 浏览器测试
我们使用 Laravel Dusk 编写端到端浏览器 UI 测试。Laravel Dusk 在幕后使用 Selenium,你可以使用它轻松地自动测试应用程序在 Chrome、Firefox 和 Edge 上(以及 Safari,但也有一些限制)。你也可以选择使用通用的浏览器自动化框架,例如 Cypress 或 Playwright。但是,如果你可以使用应用程序的数据库模型来设置测试数据,并使用与后端测试相同的断言,我建议你坚持使用基于 PHP 的浏览器测试。
这里有一个警告:编写 Laravel Dusk 测试(以及通常的基于浏览器的测试)可能非常耗时(有时也很令人沮丧)。我们拥有一个广泛的 Dusk 测试库,用于 Testmo,该库会自动测试我们添加到 Testmo 的每个功能。但你不必这样做。任何浏览器测试都比没有测试好。因此,如果你决定只测试应用程序中的某些成功路径,或构建一些初始冒烟测试以点击最重要的功能,这是一个很好的开始。
我之前已经写过有关 Laravel Dusk 浏览器测试技巧,因此你可能会发现它很有用。
前端测试
我们在上面介绍了后端测试和基于 UI 浏览器的测试。你可能想知道为什么我们现在还需要额外的、独立的前端测试来测试我们的 JavaScript 代码。原因很简单:如今越来越多的代码在浏览器中运行,因此除了我们的端到端 UI 测试之外,我们还希望有一种方法来运行 JavaScript 中的单元测试来测试此类代码。
这里有一个简单的例子。在 Testmo 中,我们允许用户导入现有数据以进行 测试用例管理。客户可以从 Excel 导入数据,或者从旧的、遗留的产品迁移数据,并将他们的测试用例带到新的系统中。
客户可能拥有他们想要导入的大量现有的测试用例库。为了加快导入和解析数据的速度,我们在将它们提交给 Testmo 之前,实际上是在浏览器中处理导入文件。为此,我们构建了针对不同格式(例如 CSV/Excel 文件)的导入解析器。使用纯基于 Selenium 的测试来测试此类代码会很困难且速度很慢,因此我们为 JavaScript 库和助手添加了额外的前端测试。
编写和运行 JavaScrip 测试有很多选择。我们自己使用 Mocha/Chai 进行测试,并对此非常满意。
Laravel 测试 CI 集成
测试只有在定期运行时才有用。确保在更改应用程序时运行所有测试的最佳方法是将它们集成到你的 CI 管道中。这通常使用流行的平台来实现,例如 GitHub Actions、GitLab CI/CD 或 CircleCI。这有几个优点
- 如果你养成只部署通过所有测试的构建的习惯,你将自动获得构建更好(更快速)测试的动力
- 在 CI 环境中运行测试通常有助于找到由于时间问题而失败的脆弱测试。当你刚开始编写浏览器测试时,这种情况经常发生,因此最好尽早学习它。
- 你可以更容易地使用并行测试作业来设置和运行测试,从而显著加快测试执行速度。例如,对于 Testmo,依次运行所有测试将需要数小时。使用并行测试,我们可以在不到 30 分钟的时间内运行所有测试套件。
你可能还会发现我之前关于将 Laravel Dusk 集成到 GitHub Actions 的文章有用。
手动和探索性测试
最后但同样重要的是,我们仍然会对新功能进行大量 探索性测试 和手动测试,或者作为新构建和发布的冒烟测试。如果你拥有专门的测试团队,那么使用 Testmo 等工具通常很重要,这样你就可以规划、管理、分配和跟踪所有测试。如果你是一位独立的开发人员或没有专门的测试人员的开发团队,那么从电子表格开始通常是一个不错的选择。
如果我只能给出关于构建更好的 Laravel 应用程序的一条建议,我会建议尽早开始考虑测试。与试图在后期修复问题相比,在开发过程中并行构建测试要容易得多。如果没有广泛的自动化测试,更复杂的应用程序很快就会变得难以维护,因此在构建测试套件上花费的初始时间会在以后为你节省大量时间。
这篇文章由 Testmo 的创始人之一 Dennis Gurock 撰写。Testmo 使用 Laravel 构建,帮助团队在一个现代平台上管理所有软件测试。如果您不熟悉 QA 工具,Testmo 最近发布了各种工具指南,帮助您入门。