测试框架选择: xUnit族理论

Question

背景：

我熟悉xUnit族框架，并有过(shunit2、PhpUnit和最简单的)经验。目前，我正试图为C++找到一个测试框架。我使用维基百科文档框架列表快速搜索了框架；但是，我想要使用的框架很难设置，而且文档也很糟糕。我尝试过的另一个框架(IMHO)非常容易设置并集成到我的生产工作流程中。

我选择的框架(很难设置的框架)和我目前使用的框架(易于安装的框架)之间的区别在于是否符合xUnit方法。

问题：

1. 我读过很多关于xUnit测试框架的文章。我认为他们在测试中使用了类似的命名约定和测试方法。这是真的吗?使用的命名方法是什么？

1. 使用xUnit测试框架是否会使使用多种语言时更容易运行集成测试？

1. 从培训的角度来看，教给新程序员一套基于相同概念的工具还是不同的单个工具来做同样的事情是否更符合成本效益？

我保留的框架是匿名的，因为我对行业最佳实践更感兴趣，而不是将这两个框架进行比较。

Answer 1

我发现，虽然同一家族中的一组工具听起来应该是相同的(具体来说，我想到的是log4x，它是一个很棒的日志库，比.net日志之类的东西好得多)，但它的配置和使用仍然有很大的不同，几乎可以作为单独的工具。

因此，我不会停留在一个单一的工具系列，并会使用任何你最喜欢的工具，不管它的来源。

我发现这种想法在微软的世界里很流行--“我们在这里使用微软”，不管微软的工具有多糟糕，或者非微软的工具有多棒，有些人根本不会使用好的东西，而且会坚持微软给他们的任何东西。( IBM过去也是如此，我相信其他地方也有相同的心态)。这里的问题是，他们把自己局限在这样的想法上，那就是外面有更好的东西。

所以，使用您认为最好的工具。如果您(和其他人)拒绝使用非xUnit测试框架，那么人们就没有什么动力想出解决问题的新的、更好的方法。使用质量更好的产品是行业最佳实践IMHO。

Answer 2

我还没有在C++中做过TDD，但我目前正在阅读如何有效地使用遗留代码，我的第一反应是使用Michael推荐的内容。

1. 在我的经验中，比事物的名称更重要的是概念。因此，在xUnit风格中，您有一个测试套件的概念，它包含一组测试、一个设置过程和一个拆卸过程。安装程序在套件中的每个测试之前运行，在每个测试之后运行拆卸。因此，任何具有这些概念的框架对于具有xUnit经验的人来说都应该很容易适应。
2. 集成测试与单元测试不同。xUnit风格的框架并不真正关注集成。网络爱好者已经开发了专门的工具，可以“自动引导”Web浏览器来测试网站行为，但我相信像Fitnesse这样的工具会采取更普遍的方法，它允许您指定系统的预期输入和输出，并测试这些输入和输出是否满足。我要说的是，您希望关注自动化工具--尤其是查看您的构建工具是否能够理解您的测试框架输出，并将其以报告、通知等形式呈现出来。仅仅将内容打印到控制台是不够的--它必须能够提供您的持续集成系统可以用来检查构建成功和测试通过/失败(例如Travis CI)的东西。
3. 我不太明白--这似乎太笼统了。但见第一。