我目前在一家大型知名公司的测试工具和框架团队工作。因此,虽然我不是专家,但这是我工作的一部分。我将专门讨论网络测试。对于 iOS 和 Android 等本机应用程序来说,测试有些不同,我对这些方面不太熟悉。
e2e(端到端)和集成测试之间的术语在某种程度上可以互换,而单元测试有更具体的定义。
一般来说,e2e/集成测试应该可以在开发和生产环境中运行。根据您的设置,您的开发环境可能正在使用生产数据库的一些半频繁更新的快照。在其他情况下,您的本地环境可能会访问实际的生产数据库。两种方法都各有利弊,但这在很大程度上取决于您公司或项目的规模。例如,如果您在一家拥有专门团队的大公司,您每天可以看到生产数据库发生许多更改,而在小团队中,生产数据库的每周快照可能足以进行本地测试。
我
在基础层面,所有集成测试都应该被视为真实的。在处理 Web 应用程序时,我们必须考虑许多其他因素,例如不同的 Web 浏览器、网络活动/可用性等。因此,模拟 api 调用的数据将允许超快速测试,但会增加另一层复杂性确保模拟与现实世界的数据库保持同步。
在本地运行集成测试或多或少应该对您的开发服务器执行与针对登台和生产执行的相同操作。除了让应用程序检测其是否在开发、登台或生产环境中运行以切换 URL 和各种凭据之外,应用程序的行为方式应该完全相同。
关于您的身份验证问题,答案是肯定的。让我们看两个显示不同考虑因素的示例。
假设您的项目非常小。您在生产中创建一些真实帐户,并且您的数据库每周都会生成快照以在本地开发环境中使用。您只需根据需要与其中一个或多个用户运行集成测试即可。由于本地测试仅访问本地数据库,因此您无需担心生成的数据,因为它不会影响生产。您团队中的其他工程师可以使用相同的用户,而不必担心。如果一位工程师对数据库模式、ORM 等进行了一些更改,那么每个人都会获得数据库快照的新副本并继续工作。
现在来说另一个极端。假设你的项目非常大。每天都有数百万用户和数百名员工集体对代码库和数据库进行更改。设置基础设施可以通过多种方式来处理各种工程任务。数据太多且数据库更改太频繁,以至于无法使用本地快照。在这种规模下,您可能会进行持续集成并在每次提交时运行测试。您希望这样做,以便传入的更改不会进入生产并导致重大问题。您可能正在针对不断更新的临时数据库甚至针对生产数据库本身运行本地开发环境。 (尝试规划临时数据库,因为它可以避免许多其他问题。)
现在,只有一小部分专门的测试用户开始成为一个问题。测试一直在自动进行,并且由数十名工程师进行各自的工作。由于登台数据库可能是共享的,因此您很容易开始遇到奇怪的冲突,因为同一个测试用户正在执行各种操作并开始导致测试失败。我见过的一个很好的解决方案是一种测试帐户结账服务器。您创建 100 个或 1000 个(或更多)测试用户帐户。当集成测试运行时,它们实际上会从服务器检查测试用户帐户。测试完成后,集成测试会清除对该用户所做的任何更改,并告诉结帐服务器该用户再次空闲。然后它会随机地被某人/其他人检查,并且循环继续。
因此,与您的问题直接相关的要点是:
- 您应该始终拥有与常规用户帐户完全相同的专用测试用户帐户,仅用于测试。
- 根据团队和项目的规模,如果规模较小,几个专用帐户就可以了。如果工作规模更大,您需要更多专用测试帐户,并且可能需要一个自动化服务,允许单独的测试运行根据需要检查用户。
- 测试应该始终自行清理。如果测试创建了存储在数据库中的 TODO。当测试运行完成后,应该从数据库中删除该 TODO。如果您对此不一致,您最终会遇到数据不一致的错误和问题。上帝禁止这种情况在生产中发生。
- 只需担心单元测试的模拟数据,除非您在一个非常良好且专用的工程环境中工作,其中有人致力于使数据库模拟始终保持最新状态。如果你can这样做,您的集成测试将非常快,并且您实际上不必担心数据库的问题。但如果没有专门的支持,很难长期维持这种状态。