有什么推荐的策略可以将单元测试与集成测试分离，从而使我们可以轻松地从Hudson进行运行，同时允许对单个单元测试和两种测试组合的代码覆盖率进行统计？ （我假设仅从集成测试中获取代码覆盖率统计数据没有任何价值，但是如果您认为这是一个错误的假设，也请让我知道。）
具体来说，这是Java应用程序，其中使用Maven作为构建管理器，使用Subversion作为版本控制系统，大多数开发人员使用NetBeans IDE，并且还大量使用Spring以及一些新的JMockit和AspectJ代码。我想知道的事情是：
当前，NetBeans有一个工具可以自动为您创建单元测试。它将它们置于src \ test目录层次结构中，该目录层次结构反映了主项目的src \ main目录层次结构。我应该创建一个src \ integrationTest目录还是专门用于集成测试的目录，以使其易于分离，还是通常使用命名约定来区分这两种类型的测试，或者是一个注释？与＃1相同，是否有用于将集成测试与单元测试分离的Maven模式？
是否有用于Subversion的标准签入钩子，以强制开发人员在运行之前运行单元测试，而不是集成测试报到？ （最后一个不如＃1或＃2重要，但仍然不错。）
另外，如果您有使用不同工具进行此操作的经验，我也想听听您的做法。可能是另一套工具的良好做法很简单地映射到我的工具集。
#1 楼
> The integration tests can sometimes take a long time,
> thus discouraging users from running the entire test
> suite prior to checking in
对于签入运行，您可以使用其自己的类别标记长期运行的测试
，并告诉测试运行器排除那些长期运行的测试器
您可能还会看到，是否有一种方法可以将长时间运行（例如压力测试）分离出来，以便它们在Maven 2中默认情况下不会运行？
#2 楼
要回答问题1：是的，我将单元测试代码与集成测试代码分开。它们在逻辑上是不同的，可能是不同的构建，并且您打算以不同的方式运行它们。为了更加清楚起见，我也将它们命名为不同的名称。例如，我们的单元测试位于ut_ *目录中，名称为ut_classname，因此我将集成测试放在it_ *目录中，并将其命名为it_something。关于代码覆盖率，我将我不熟悉Maven或Hudson，但是一种策略是在主构建循环之后仅对每次提交（快速）运行单元测试。当然，代码覆盖率会更低。因此，您将在第一个构建循环之后触发第二个构建循环，该循环将同时运行快速单元测试和慢速集成测试，从而为您提供合并的覆盖范围。或者，如果集成测试花费的时间很长，则可以将它们从触发的构建循环移至每小时/每晚的计划，尽管频率越高越好。假设仅从集成测试中获取代码覆盖率统计数据没有任何价值，但是如果您认为这是一个错误的假设，也请让我知道。）我没有可以看到任何一个值。单元测试应该非常快地运行，因此在运行集成测试时没有真正的理由要排除它们。
#3 楼
我个人将以合理的方式分开测试。如果您有一个允许在执行工具中进行测试分类测试列表或代码中的属性的系统，那么我将利用它。首先运行单元测试，然后运行，如果通过则允许开发人员签入，一旦签入，然后运行集成测试，如果通过，则将代码提交到主分支或主干。您希望保持您的开发人员的敏捷性，并允许他们尽快高效地工作，但仍将集成测试作为质量的“门”。
评论
那就是我想要做的，但是我想知道的是推荐的做法是什么？我将重写问题以使其更清楚。
–本·霍金
11年6月23日在10:24
@Ben在您的评论中有关于T的我的公司的故事。我老板的老板说：“我们都有很好的主意；没有短缺的货源。但是，我们如何实际实施它们呢？”大概一个月三遍。
–corsiKa♦
2011年6月23日17:20
评论
真好我真的很喜欢这两个建议。
–本·霍金
2011年6月28日上午10:52