我一直在努力学习如何为新项目中的所有代码进行正确的单元测试并设置单元测试。我目前正在执行此项目的项目要求我针对Google BigQuery运行大量操作(即创建表,插入,查询,删除)。我觉得我不能通过模拟BigQuery来真正测试所有这些功能,因为我对它做的动作是复杂和相互依赖的,如果在某个地方有中断,我想抓住它。是否通常不赞成使用环境变量来指定我的单元测试中内置的测试帐户,以便它们实际上针对远程服务运行?这感觉就像是真正测试一切的最佳方式,并且打出了我无法用模拟测试的测试。那么,这是人们做的事吗?以这种方式做事有一些重大缺点吗?
答案 0 :(得分:2)
我倾向于在我的项目中混合使用单元和集成测试。我相信两者同样有价值,但在进行集成测试时要记住的一件事是确保测试稳定且可重复。 有几种方法,但我赞成通过确保在测试本身中构建所有数据依赖性来使测试自给自足的方法。这很重要,因为您可以避免由于对数据源中现有数据的假设失败而导致测试失败。
对此的一个变体是使用脚手架脚本使用固定的测试数据填充数据源。我发现这样做不易管理,因为它可以在测试之间引入依赖关系,并且更改一个测试的测试数据可能会导致另一个测试数据失败。
答案 1 :(得分:1)
您要做的是技术上称为集成测试,但我确实看到了您的观点。我自己也在做这两件事。我在集成测试中的交互是使用数据库。我发现这些集成测试通常比真正的单元测试更容易出错,并且通常更有益。不过我会说单元测试也很重要。
我发现集成测试可能会花费更长的时间,因为它正在进行所有这些交互,如果这是您每晚构建过程的一部分,例如这会大大增加构建所需的时间完成。我们的一些构建在这一点上需要将近一个小时才能完成,这对我们来说有时是一个问题。
我会说当你将环境变量之类的东西引入混合时,你必须开始确保团队中的每个开发人员都有这个环境变量,如果他们想要运行测试。作为一般经验法则,我尝试尽可能简单地让每个人直接从源代码控制中构建和运行测试。没有什么比不能直接从源代码控制构建源代码或执行单元测试更令人沮丧。
答案 2 :(得分:0)
将BigQuery之类的东西视为实施细节是有帮助的;意味着结束。
您应用程序中的某些内容当前表示"我需要x
- 我将使用BigQuery来获取它。"而不是明确了解BigQuery,这件事可以反而知道某些实体能够获得x
"。这是seam的位置,是嘲笑的地方。
您提到您不想模拟创建BigQuery请求所涉及的所有对象。 你完全可以避免这种情况。但这并不代表你不能嘲笑BigQuery。你只需要move up a rung。