在单元测试中查找失败模式答案

【问题标题】：Finding patterns of failure in a Unit Test在单元测试中查找失败模式
【发布时间】：2010-03-26 21:13:33
【问题描述】：

我是单元测试的新手，我只是进入构建测试套件的日常工作。我有一个相当大的项目，我想从一开始就为其构建测试。

我正在尝试找出构建测试套件的一般策略和模式。当您查看课程时，显然由于课程的性质，您会遇到许多测试。假设具有基本 CRUD 操作的“用户帐户”类与数据库表相关，我们将要测试 - 嗯，CRUD。

至于如何破坏，大多数 CRUD 类都有“失败”测试，例如：

等等等等。

对于与文件操作有关的单元测试，“破坏事物”的列表可能是

我很确定类似的模式 - 适用于当前正在进行的单元测试之外 - 可以在大多数正在测试的单元中找到。

现在我的问题是：

【问题讨论】：

【解决方案1】：

你基本上是对的。寻找可能破坏代码的方法是单元测试的关键部分和技能。但是，在 TDD 中应用的单元测试的工作方式略有不同。在 TDD 中，您首先为一项新功能编写测试，然后创建代码以使该测试通过。所以这里的重点是不同的，尽管最终的结果是相似的。

在 TDD 中，一个人不断地“更换帽子”——一点点测试，一点点编码。所以在这种方法中，测试不是自动化的部分，但几乎可以说它是创作过程的关键。在编写测试时，您也在设计单元的界面，并从其（未来）客户的角度思考——他们可以期待什么，他们应该提供什么？然后你换掉帽子，走进单位来满足这些期望。

所以我觉得这不能通过简单地检查列表中的项目来代替。当然，一旦你用尽了测试实际单元的想法，检查这样的列表永远不会有什么坏处。然而，此类表格就其性质而言只能包含可能适用于或可能不适用于特定项目和要测试的特定类的概括。但是你显然有经验和心态来为你的特定单元找到好的测试用例:-)

【讨论】：

谢谢彼得。我仍在寻找解决该主题的方法，并且仍然不确定我是否做对了，所以我很高兴能够在这里获得高质量的反馈。只是当我第二次编写基本相同的测试时，我的懒人的本能敲响了警钟:) 但我理解你关于 TDD 的观点以及如何自动化这不是重点。我注意到我通过先编写测试，然后编写单元慢慢滑入其中，这是一种非常好的工作方式。
@Pekka 实践成就大师，这是真正获得它的唯一方法 :-) 顺便说一句，Pekka 是芬兰名字，你是芬兰人吗？
@Peter 确实如此。重新起源：一半一半。我出生在芬兰，但在德国长大，所以我几乎是德国人。不过，我还是会说一点芬兰语。