什么是好的单元测试？
我敢肯定，你们中的大多数人都在编写大量的自动化测试，并且在进行单元测试时也遇到了一些常见的陷阱。
我的问题是，我们是否遵循任何编写测试的行为准则，以避免将来出现问题？更具体地说：好的单元测试的属性是什么？如何编写测试？
鼓励与语言无关的建议。
解决方案
回答
牢记这些目标(改编自Meszaros的xUnit Test Patterns)
- 测试应该降低风险，而不是引入风险。
- 测试应该易于运行。
- 随着系统围绕测试的发展，测试应该易于维护
一些使这更容易的事情：
- 测试应该仅由于一种原因而失败。
- 测试只能测试一件事
- 最小化测试依赖性(不依赖数据库，文件，UI等)
别忘了我们也可以使用xUnit框架进行集成测试，但要将集成测试和单元测试分开
回答
- 不要编写繁琐的测试。正如"单元测试"中的"单元"所暗示的那样，应使每个单元尽可能原子且隔离。如果需要，请使用模拟对象创建前提条件，而不是手动重新创建太多的典型用户环境。
- 不要测试明显起作用的东西。避免测试第三方供应商提供的类，尤其是那些提供我们所编码框架的核心API的供应商。例如，请勿测试将任何项目添加到供应商的Hashtable类中。
- 考虑使用诸如NCover之类的代码覆盖工具来帮助发现尚未测试的极端情况。
- 尝试在实现之前编写测试。将测试视为实现将遵循的更多规范。 cf.也是行为驱动的开发，这是测试驱动的开发的一个更具体的分支。
- 始终如一。如果只为某些代码编写测试，则几乎没有用。如果我们在团队中工作，而其他一些或者所有其他人都不编写测试，那么它也不是很有用。让自己和其他所有人相信测试的重要性(以及节省时间的属性)，或者不要打扰。
回答
我们所追求的是描述被测类的行为。
- 验证预期行为。
- 验证错误案例。
- 该类中所有代码路径的覆盖范围。
- 行使课程中的所有成员函数。
基本目的是增强我们对课堂行为的信心。
这在查看重构代码时特别有用。 Martin Fowler在他的网站上有一篇有趣的文章，关于测试。
HTH。
干杯，
抢
回答
测试最初应该失败。然后，我们应该编写使它们通过的代码，否则，我们将冒编写有漏洞且始终通过的测试的风险。
回答
- 单元测试仅测试单元的外部API，而不应该测试内部行为。
- 测试测试范围：一旦测试了一个单元，就应该已经执行了该单元内部100％的行。
回答
永远不要认为平凡的2行方法会起作用。编写快速的单元测试是防止丢失的空测试，放负号和/或者细微的范围错误咬住唯一方法，这是不可避免的，因为与现在相比，处理时间更少了。
回答
优秀的单元测试的一些属性：
- 如果测试失败，应该立即发现问题所在。如果我们必须使用调试器来查找问题，则测试不够精细。每个测试只有一个断言会有所帮助。
- 重构时，任何测试都不应失败。
- 测试应该运行得如此之快，以至于我们可以毫不犹豫地运行它们。
- 所有测试应始终通过；没有确定性的结果。
- 就像生产代码一样，单元测试应精心设计。
@Alotor：如果我们建议一个库应该只在其外部API上进行单元测试，那么我不同意。我想要每个类的单元测试，包括我不公开给外部调用者的类。 (但是，如果我觉得需要为私有方法编写测试，则需要重构。)
编辑：关于"每个测试一个断言"引起的重复的评论。具体来说，如果我们有一些代码来设置场景，然后想要对其进行多个声明，但每个测试只有一个声明，则可以在多个测试之间复制设置。
我不采取这种方法。相反，我针对每种情况使用测试夹具。这是一个粗糙的例子：
[TestFixture]
public class StackTests
{
[TestFixture]
public class EmptyTests
{
Stack<int> _stack;
[TestSetup]
public void TestSetup()
{
_stack = new Stack<int>();
}
[TestMethod]
[ExpectedException (typeof(Exception))]
public void PopFails()
{
_stack.Pop();
}
[TestMethod]
public void IsEmpty()
{
Assert(_stack.IsEmpty());
}
}
[TestFixture]
public class PushedOneTests
{
Stack<int> _stack;
[TestSetup]
public void TestSetup()
{
_stack = new Stack<int>();
_stack.Push(7);
}
// Tests for one item on the stack...
}
}
回答
测试应隔离。一种测试不应依赖于另一种。更进一步，测试不应依赖于外部系统。换句话说，请测试代码，而不是代码所依赖的代码。我们可以在集成或者功能测试中测试这些交互。
回答
通常，单元测试基于模拟对象或者模拟数据。
我喜欢编写三种单元测试：
- "瞬态"单元测试：它们创建自己的模拟对象/数据并使用其测试其功能，但销毁所有内容并且不留下任何痕迹(例如测试数据库中没有数据)
- "持久"单元测试：它们在代码中测试创建对象/数据的功能，这些功能稍后将由更高级的功能用于其自身的单元测试(避免那些高级功能每次在其自己的一组模拟对象/数据中都重新创建)
- "基于持久"的单元测试：使用持久单元测试已经存在的模拟对象/数据(由于在另一个单元测试会话中创建)的单元测试。
关键是要避免重播所有内容以便能够测试每个功能。
- 我经常运行第三种，因为所有模拟对象/数据都已经存在。
- 每当我的模型改变时，我都会运行第二种。
- 我运行第一个脚本，不时检查非常基本的功能，以检查基本回归。
回答
考虑一下这两种测试，并分别对待它们进行功能测试和性能测试。
分别使用不同的输入和指标。对于每种类型的测试，我们可能需要使用不同的软件。
回答
杰伊·菲尔德斯(Jay Fields)在编写单元测试方面有很多很好的建议，并且他在帖子中总结了最重要的建议。在那里，我们将了解到，我们应该认真考虑自己的情况，并判断建议是否对我们有价值。我们可以在此处获得大量令人惊奇的答案，但是由我们决定哪个最适合情况。尝试一下，如果气味对我们不好，请进行重构。
亲切的问候
回答
让我首先使用JUnit插入Java中的实用单元测试源(也有一个带有C＃-Nunit的版本..但是我有这个版本。在很大程度上与它无关。建议。)
好的测试应该是一个旅行(首字母缩略词不够粘稠，我在书中有一份速查表的打印输出，为了确保我理解正确，我不得不将其抽出。)
- 自动：测试的通过以及通过/失败的检查结果应该是自动的
- 彻底：覆盖范围；尽管错误倾向于聚集在代码中的某些区域，但是请确保测试所有关键路径和方案。如果必须了解未测试的区域，请使用工具
- 可重复：每次测试都应产生相同的结果。测试不应依赖无法控制的参数。
- 测试不应相互依赖-隔离。没有关于测试执行顺序的假设。每次测试前，请通过适当使用设置/拆卸来确保"干净"
- 专业：从长远来看，我们将拥有与生产一样多的测试代码(如果不是更多的话)，因此对于测试代码，请遵循相同的良好设计标准。精心设计的方法类-具有意图揭示名称，无重复，具有良好名称的测试等。
- 好的测试也可以快速运行。任何需要半秒以上才能运行的测试都需要进行。测试套件运行的时间越长..运行频率越低。开发人员将尝试在两次运行之间进行更多的更改..如果有任何中断..将花费更长的时间来找出哪个更改是罪魁祸首。
2010-08更新：
- 可读：可以认为这是Professional的一部分-但是压力不够大。严峻的考验是找到不属于我们团队的人，并要求他/她在几分钟内找出被测行为。测试需要像生产代码一样进行维护-因此即使花费更多的精力也可以使其易于阅读。测试应该对称(遵循模式)并且简洁(一次测试一种行为)。使用一致的命名约定(例如TestDox样式)。避免使"偶然的细节"使测试混乱。
除此之外，其他大多数都是减少低效益工作的准则：例如"不要测试我们不拥有的代码"(例如第三方DLL)。不要去测试吸气剂和吸气剂。留意成本效益比或者缺陷概率。
回答
我喜欢上述实用单元测试书中的Right BICEP缩写：
- 正确：结果正确吗？
- B：所有边界条件都正确吗？
- I：我们可以检查逆关系吗？
- C：我们可以使用其他方式对结果进行交叉检查吗？
- E：我们可以强制发生错误情况吗？
- 警：性能特征是否在范围之内？
我个人认为，可以通过检查是否得到正确的结果(在加法函数中1 + 1应该返回2)，尝试所有可以想到的边界条件(例如使用两个数字之和来求和)，可以走得很远。大于add函数中的整数最大值)，并强制出现错误情况(例如网络故障)。
回答
我在《 MSDN杂志》的这篇文章中提到了这些原则，我认为这对任何开发人员来说都是重要的。
我定义"好的"单元测试的方式是，它们是否具有以下三个属性：
- 它们是可读的(命名，断言，变量，长度，复杂度..)
- 它们是可维护的(无逻辑，未过度指定，基于状态，已重构..)
- 他们是值得信赖的(测试正确的东西，孤立的，而不是集成测试..)
回答
我第二次回答" A TRIP"，只是测试应该相互依赖！！！
为什么？
DRY不要重复自己也适用于测试！测试依存关系可以帮助1)节省设置时间，2)节省夹具资源，以及3)查明故障。当然，仅考虑到测试框架支持一流的依赖关系。否则，我承认，它们是不好的。
跟进http://www.iam.unibe.ch/~scg/Research/JExample/
回答
好的测试需要维护。
我还没有弄清楚如何在复杂的环境中执行此操作。
当代码库开始覆盖时，所有教科书都开始脱胶
成千上万或者几百万行代码。
- 团队互动激增
- 测试用例数量激增
- 组件之间的相互作用会爆炸。
- 建立所有单元测试的时间成为构建时间的重要部分
- API更改可能会影响到数百个测试用例。即使生产代码更改很容易。
- 将进程排序为正确状态所需的事件数量增加了，这反过来又增加了测试执行时间。
好的架构可以控制某些交互爆发，但不可避免
系统变得更加复杂，自动化测试系统也随之发展。
这是我们开始权衡取舍的地方：
- 仅测试外部API，否则重构内部会导致大量的测试用例返工。
- 随着封装子系统保留更多状态，每个测试的设置和拆卸都会变得更加复杂。
- 每晚编译和自动测试执行需要数小时才能完成。
- 增加的编译和执行时间意味着设计师不会或者不会运行所有测试
- 为了减少测试执行时间，我们可以考虑对顺序测试进行操作，以减少设置和拆卸时间
我们还需要确定：
我们将测试用例存储在代码库中的什么位置？
- 我们如何记录测试用例？
- 测试夹具可以重新使用以节省测试用例维护费用吗？
- 夜间测试用例执行失败时会发生什么？谁进行分类？
- 我们如何维护模拟对象？如果我们有20个模块都使用它们自己的模拟日志记录API风格，则快速更改API会产生波动。测试用例不仅发生变化，而且20个模拟对象也发生变化。这20个模块是由许多不同的团队在几年内编写的。这是一个经典的重用问题。
- 个人和他们的团队了解自动化测试的价值，他们只是不喜欢另一个团队的工作方式。 :-)
我可以永远继续下去，但我的意思是：
测试必须是可维护的。
回答
这里的大多数答案似乎都是针对一般的单元测试最佳实践(何时，何地，为什么以及什么)，而不是实际编写测试(如何)。由于问题似乎在"如何"部分上非常具体，因此我认为应该从我在公司进行的"棕色袋子"演示文稿中发布。
Womp的五项写作定律：
1.使用描述性长的测试方法名称。
- Map_DefaultConstructorShouldCreateEmptyGisMap() - ShouldAlwaysDelegateXMLCorrectlyToTheCustomHandlers() - Dog_Object_Should_Eat_Homework_Object_When_Hungry()
2.以"编配/执行/声明"样式编写测试。
- 尽管这种组织策略已经存在了一段时间，并引起了许多关注，但最近引入" AAA"首字母缩略词已经成为解决这一问题的好方法。使所有测试与AAA风格保持一致，使它们易于阅读和维护。
3.始终向断言提供失败消息。
Assert.That(x == 2 && y == 2, "An incorrect number of begin/end element processing events was raised by the XElementSerializer");
- 一种简单而有益的做法，使运行者应用程序可以清楚地发现失败了。如果不提供消息，则故障输出中通常会出现" Expected true，was false"之类的信息，这使我们必须实际阅读测试以找出问题所在。
4.评论测试的原因是什么业务假设？
/// A layer cannot be constructed with a null gisLayer, as every function
/// in the Layer class assumes that a valid gisLayer is present.
[Test]
public void ShouldNotAllowConstructionWithANullGisLayer()
{
}
- 这看起来似乎很明显，但是这种做法可以保护测试的完整性，避免那些一开始不了解测试背后原因的人。我已经看到许多测试都被删除或者修改得很好，这仅仅是因为该人不了解该测试正在验证的假设。
- 如果测试很简单或者方法名称具有足够的描述性，则可以省略注释。
5.每个测试都必须始终还原其接触的任何资源的状态
- 尽可能使用模拟以避免处理实际资源。
- 清理必须在测试级别完成。测试不得依赖于执行顺序。
回答
我使用Roy Osherove的单元测试命名标准描述的一致的测试命名约定。给定测试用例类中的每个方法都具有以下命名方式MethodUnderTest_Scenario_ExpectedResult。
第一个测试名称部分是被测系统中方法的名称。
接下来是正在测试的特定方案。
最后是该方案的结果。
每个部分均使用上驼峰式保护套，并由得分下限定界。
在运行测试时，我发现这很有用，因为测试按被测方法的名称分组。并有一个约定允许其他开发人员了解测试意图。
如果被测方法已重载，我还将参数添加到"方法名称"上。
