集成测试最佳实践

5 回答

• 14

  您是否已完成任何测量（使用计时器或类似工具）以确定测试在大部分时间内的使用时间？

  如果您已经知道数据库重新创建是他们耗费时间的原因，那么不同的方法是重新生成数据库一次并使用事务来保持测试之间的状态 . 每个CUD类型测试都会在设置中启动事务并在拆卸时执行回滚 . 这可以显着减少每次测试数据库设置所花费的时间，因为事务回滚比完整数据库重新创建便宜 .

  回复于 2024-04-20T10:39:53+08:00
• 3

  我是一名java开发人员，但处理过类似的问题 . 我发现运行本地数据库实例的速度很快（没有数据通过网络发送），并且因为这样您就不会在集成测试数据库上发生争用 .

  我们用于解决此问题的一般方法是设置构建脚本以从配置文件中读取数据库连接字符串，然后为每个环境设置一个文件 . 例如，一个用于WORKSTATION的文件，另一个用于CI的文件 . 然后设置构建脚本以根据指定的环境读取配置文件 . 因此，在使用WORKSTATION配置运行的开发人员工作站上运行的构建，并且在CI环境中运行的构建使用CI设置 .

  如果可以从单个脚本创建整个数据库模式，那么它也会有很大帮助，因此每个开发人员都可以快速设置本地数据库进行测试 . 您甚至可以将此概念扩展到下一个级别，并将数据库设置脚本添加到构建过程，因此可以编写整个数据库设置以跟上数据库架构中的更改 .

  回复于 2024-04-20T10:39:53+08:00
• 3

  将快速（单位）和慢速（积分）测试分开，以便您可以单独运行它们 . 使用测试框架提供的任何分组/分类测试方法 . 如果测试框架不支持对测试进行分组，请将集成测试移动到仅具有集成测试的单独模块中 .

  快速测试应该只需要几秒钟来运行所有这些测试，并且应该具有高代码覆盖率 . 这些测试允许开发人员无情地重构，因为他们可以进行一些小的更改并运行所有测试，并且非常确信更改不会破坏任何内容 .

  慢速测试可能需要几分钟才能运行，它们将确保各个组件正确地协同工作 . 当开发人员进行的更改可能会破坏集成测试而不是单元测试所测试的内容时，他们应该在提交之前运行这些集成测试 . 否则，慢速测试由CI服务器运行 .

  回复于 2024-04-20T10:39:53+08:00
• 5

  在NUnit中，您可以使用属性来装饰您的测试类（或方法），例如：

  [Category("Integration")]
  public class SomeTestFixture{
      ...
  }
  [Category("Unit")]
  public class SomeOtherTestFixture{
      ...
  }
  

  然后，您可以在服务器上的构建过程中规定所有类别都运行，并且只需要您的开发人员运行可用测试类别的子集 . 他们需要运行的类别取决于您将比我更了解的事情 . 但要点是他们能够在单元级别进行测试，服务器可以处理集成测试 .

  回复于 2024-04-20T10:39:53+08:00
• 11

  我们有一个SQL Server Express实例，它为每个开发机器运行相同的数据库定义，作为开发环境的一部分 . 使用Windows身份验证，连接字符串是稳定的 - 字符串中没有用户名/密码 .

  我们真正想做的，但还没有，看看我们是否可以让我们的系统在SQL Server Compact Edition上运行，这就像SQLite的SQL Server引擎一样 . 然后我们可以在内存中运行它们，也可以并行运行它们（使用多个进程） .

  回复于 2024-04-20T10:39:53+08:00