在单元测试中查找失败模式-解网

问：

我是单元测试的新手，我只是开始构建测试套件。我有一个相当大的项目，我想从一开始就为它构建测试。

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

至于如何打破常规，大多数 CRUD 类都有常见的“失败”测试，例如：

依此类推。

对于与文件操作有关的单元测试，“中断性内容”列表可能是

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

现在我的问题是：

我看到这种“突破模式”是正确的吗？还是我在单元测试方面完全错了，如果我做对了，这根本不是问题？单元测试是一个寻找尽可能多的方法来破坏单元的过程，这是正确的方法吗？
如果我是对的：是否有针对此类模式的现有定义、列表、备忘单？
是否有任何规定（主要是在 PHPUnit 中，因为这是我正在使用的框架）来自动化这些模式？
是否有任何帮助 - 以检查表或软件的形式 - 来帮助编写完整的测试？

php 单元测试 phpunit

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

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

所以我觉得这不能通过简单地检查列表中的项目来取代。当然，一旦你没有想法来测试实际的单位，检查这样的列表永远不会有什么坏处。但是，就其性质而言，此类工作表只能包含可能适用于也可能不适用于特定项目和特定要测试的类的概括。但是您显然有经验和心态，无论如何都可以为您的特定单元找到好的测试用例：-）

谢谢彼得。我仍在寻找这个话题的方法，仍然不确定我是否做对了，所以我很感激能够在这里获得高质量的反馈。只是当我第二次写基本上相同的测试时，我懒惰的人的本能敲响了警钟:)但我理解你对TDD的看法，以及自动化不是重点。我注意到我通过先编写测试，然后编写单元来慢慢滑入其中，这是一种非常好的工作方式。

0赞 Péter Török 3/27/2010

@Pekka熟能生巧，这是真正掌握它的唯一方法：-）顺便说一句，Pekka是一个芬兰名字，你是芬兰血统吗？

0赞 Pekka 3/27/2010

@Peter确实如此。重新起源：半半。我出生在芬兰，但在德国长大，所以我几乎是德国人。不过，我还是会说一点芬兰语。

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