问题标签 [integration-testing]

我们已经编写了自己的集成测试工具，我们可以在其中编写许多“操作”或测试，例如“GenerateOrders”。我们有许多参数可以用来配置测试（例如订单数）。然后我们编写第二个操作来确认测试已经通过/失败（即有（nt）个订单）。

该工具用于

• 集成测试
• 数据生成
• 端到端测试（通过混合和匹配多个测试）

它似乎运行良好，但是需要开发经验来维护和编写新的测试。我们的测试团队想参与进来，他们几乎没有 C# 开发经验。

我们即将开始一个新的 Greenfield 项目，我正在研究编写和维护集成测试的最佳方式。

问题如下：

• 你如何进行集成测试？
• 您使用什么工具（FitNess？、Custom？、NUnit）？

我期待着人们的建议/评论。

提前致谢，

大卫

给定软件...

• 该系统由几个子系统组成
• 每个子系统由几个组件组成
• 每个组件都使用许多类来实现

...我喜欢为每个子系统或组件编写自动化测试。

我不会为组件的每个内部类编写测试（除非每个类都有助于组件的公共功能，因此可以通过组件的公共 API 从外部进行测试/测试）。

当我重构组件的实现时（我经常这样做，作为添加新功能的一部分），因此我不需要更改任何现有的自动化测试：因为测试只依赖于组件的公共 API 和公共 API通常是扩大而不是改变。

我认为该政策与Refactoring Test Code 之类的文档形成鲜明对比，该文档说...

• “……单元测试……”
• “......系统中每个班级的测试班......”
• “......测试代码/生产代码比率......理想情况下被认为接近1：1的比率......”

...我想我不同意所有这些（或者至少不练习）。

我的问题是，如果您不同意我的政策，您能解释一下原因吗？这种程度的测试在什么场景下是不够的？

总之：

• 公共接口经过测试（和重新测试），很少更改（它们被添加但很少更改）
• 内部 API 隐藏在公共 API 之后，无需重写测试公共 API 的测试用例即可更改

脚注：我的一些“测试用例”实际上是作为数据实现的。例如，UI 的测试用例由包含各种用户输入和相应的预期系统输出的数据文件组成。测试系统意味着拥有读取每个数据文件的测试代码，将输入重放到系统中，并断言它获得了相应的预期输出。

虽然我很少需要更改测试代码（因为通常会添加而不是更改公共 API），但我确实发现有时（例如每周两次）需要更改一些现有的数据文件。当我将系统输出更改为更好（即新功能改进现有输出）时，可能会发生这种情况，这可能会导致现有测试“失败”（因为测试代码仅尝试断言输出未更改）。为了处理这些情况，我执行以下操作：

• 重新运行自动化测试套件，其中有一个特殊的运行时标志，告诉它不要断言输出，而是将新输出捕获到新目录中
• 使用可视化差异工具查看哪些输出数据文件（即哪些测试用例）已更改，并验证这些更改是否良好且符合新功能的预期
• 通过将新输出文件从新目录复制到运行测试用例的目录来更新现有测试（覆盖旧测试）

脚注：“组件”是指“一个 DLL”或“一个程序集”之类的东西……大到足以在体系结构或系统部署图中可见的东西，通常使用数十个或 100 个类来实现，并且使用仅由大约 1 个或少数几个接口组成的公共 API……可以分配给一个开发团队的东西（其中不同的组件被分配给不同的团队），因此根据康威定律有一个相对稳定的公共 API。

脚注：文章面向对象测试：神话与现实说，

误区：黑盒测试就足够了。 如果您使用类接口或规范仔细地进行测试用例设计，您可以确信该类已被充分执行。白盒测试（查看方法的实现以设计测试）违反了封装的概念。

现实：OO 结构很重要，第二部分。许多研究表明，被开发人员认为极其彻底的黑盒测试套件仅在被测实现中执行了三分之一到一半的语句（更不用说路径或状态）了。这有三个原因。首先，选择的输入或状态通常使用正常路径，但不会强制所有可能的路径/状态。其次，仅靠黑盒测试无法揭示惊喜。假设我们已经测试了被测系统的所有指定行为。为了确保没有未指定的行为，我们需要知道系统的任何部分是否没有被黑盒测试套件执行过。获取此信息的唯一方法是通过代码检测。第三，

我应该补充一点，我正在做白盒功能测试：我看到代码（在实现中）并编写功能测试（驱动公共 API）来练习各种代码分支（功能实现的细节）。

如果我对每个类和/或成员函数进行单元测试，并对每个用户故事进行验收测试，我是否有足够的测试来确保项目按预期运行？

例如，如果我对某个功能进行了单元测试和验收测试，我是否还需要集成测试，或者单元测试和验收测试是否应该涵盖相同的领域？测试类型之间是否存在重叠？

我在这里谈论自动化测试。我知道对于易用性等问题仍然需要手动测试。

我们在 Maven 中为我们的集成测试阶段生命周期定义了数百个测试，它们需要很长时间才能完成。

我想做的只是在integration-test. 我试着做：

但这不起作用。-Dtest仅运行单元测试目标中的测试，而不是集成测试阶段。我尝试了-Dintegration-test=<my-test>，但被忽略了。

有没有办法做到这一点 ？

我的配置是：

我的任务是从第三方供应商的 SQLite 数据表中提取所有行，从这些记录中创建业务对象，并将新的业务对象发送到另一个类。

伪代码：

我已经完成了所有工作。

我的问题是：我如何编写这个类以便它可以进行单元测试？

我是不是该：

• 使用存储库模式模拟数据访问
• 实际上在单元测试中提供了一个虚拟 SQLite 数据库

还是有更好的想法？我正在使用 C#，但这个问题似乎与语言无关。

我有许多 C# 集成测试使用由 cucumber 推广的 Given/When/Then 样式编写。我正在使用一个与 NBehave 基本相同的框架。

我面临的一个反复出现的问题是设置和连接集成测试所需的所有应用程序状态的问题。我的大多数测试看起来像这样：

如您所见，动作和断言是单行的，但我有 6 行“接线”。几乎我的每个测试都重复这 6 行。

这对我来说似乎是一种代码味道，但我不确定如何处理这个问题。我可以将 6 行重构为一行（Given "a valid system..."或类似的），但这似乎太过分了，我会隐藏太多信息。

我会很感激其他在这方面有更多经验的人提出的任何想法。非常感谢。

我有我的单元测试。每种测试方法都在我的系统中测试功能的逻辑单元。在我的单元测试中，外部依赖项（db、文件等）是通过使用 Mocks 和 Fakes 来处理的。

现在我不是 100% 确定我应该如何进行集成测试。我应该重复单元测试并用实际资源（数据库、文件等）替换，还是应该测试更低级别的东西，例如：

1) 可以 ping 数据库
2) 可以检索一条记录
3) 文件是否存在
等...

我的直觉是我应该在这个阶段避免商业逻辑，因为大部分应该在 Unit 中完成，对吧？

谢谢

编辑：我在撰写问题时有点懒惰，我还想知道的是，如果我需要在集成阶段测试 biz 逻辑，那么我应该如何设置我的测试套件以最大限度地减少测试代码重复。举个例子：

哪种测试结构适合您？您是否直接在集成项目中使用单元测试程序集并注入正确的资源？

我已经编写了我的单元测试，并且在需要外部资源的地方使用假货来处理。

到目前为止一切都很好。现在我面临着其他测试阶段，主要是集成，我想针对真实的外部资源（例如数据库）重复单元测试方法。

那么，对于构建单元与集成测试的测试项目有哪些建议？我知道有些人更喜欢单元和集成的单独程序集？

如何在两个程序集之间共享通用测试代码？我应该创建一个包含所有抽象测试类的第三程序集并让单元和集成继承吗？我正在寻找最大的可重用性...

我听到很多关于依赖注入（StructureMap）的噪音，如何在给定的单元+集成测试设置中使用这样的工具？

谁能分享一些智慧？谢谢

我正在尝试在我的 rails 应用程序中编写一些功能测试，在 application_controller.rb 我有这个：

运行测试时，request.subdomains不包含我正在寻找的有效子域，并且无法运行任何功能测试。

是否可以存根current_account方法或模拟request.subdomains对象？

我们使用自动化测试来验证我们的 Web 应用程序的功能。为了使测试用例中的断言更简单、更灵活，我们正在考虑引入“TestIDs”，即HTML 标记中的ID，帮助测试用例查找和验证页面上的元素。此外，这些 TestID 将允许更具体的集成测试，由于页面上的数据有限，这些测试目前是不可能的。

然而，这让我们犹豫不决：

• 引入测试 ID 意味着更改测试的测试
• 安全性- 我们会披露内部域对象 ID 和其他在页面上不可见的信息
• 标准- 根据我们如何将 TestID 放入标记中，我们很可能会违反元素或属性的预期语义使用（例如，“id”或“类”属性、其他 html 元素等）
• 干扰- TestID 可能会干扰应用程序代码
• 性能- TestID 是不必要的标记（对用户而言）并增加页面大小（仅在大页面上显着）

将 TestID 限制为测试/暂存 HTML 似乎不是一个好主意，因为我们显然想要测试将在生产中使用的代码，并且不希望我们的测试/暂存环境表现不同。事实上，我们目前在发布后针对实时系统运行部分测试套件。

您认为 TestID 是一个好主意吗？如果是，您将如何将它们放入标记中？

一些示例标记来演示我在说什么：