我是单元测试的新手，我只是进入构建测试套件的例行程序。我有一个相当大的项目，我想从一开始就构建测试。
我正在试图找出构建测试套件的一般策略和模式。当你看一堂课时，由于班级的性质，很明显会有很多考试。假设一个“用户帐户”类具有基本的CRUD操作，与数据库表相关，我们将要测试 - 好吧，CRUD。
至于如何破解事物，大多数CRUD类都有“失败”测试，例如：
依旧等等。
对于与文件操作有关的单元测试，“破坏事物”列表可以是
我非常确定类似的模式 - 适用于当前正在进行的单元测试之外 - 可以在大多数正在测试的单元中找到。
现在我的问题是：
看到这种“破碎模式”，我是否正确？或者我对单元测试有一些完全错误，如果我做对了，这根本不是问题？单元测试是一个寻找尽可能多的方法来打破单位的正确方法吗？
如果我是对的：这些模式是否有现有的定义，列表，备忘单？
是否有任何条款（主要是在PHPUnit中，因为我正在使用的框架）自动化这些模式？
是否有任何帮助 - 以检查清单或软件的形式 - 以帮助编写完整的测试？
答案 0 :(得分：4)
你基本上是对的。寻找可能破坏代码的方法是单元测试的关键部分和技能。但是，TDD中应用的单元测试工作方式略有不同。在TDD中，您首先编写一个新功能的测试，然后创建代码以使该测试通过。所以这里的重点不同，即使最终结果是相似的。
在TDD中，一个“不断改变帽子” - 一点点测试，一点点编码。因此，在这种方法中，测试不是一个可自动化的部分，但人们几乎可以说它是创作过程的关键。在编写测试时，您也在设计单元的界面，并从其（未来）客户的角度思考 - 他们可以期待什么，以及他们应该提供什么？然后你换帽子进入单位以满足这些期望。
因此，我不认为只需检查列表中的项目就可以取代它。当然，一旦你用完了想法来测试实际的单元，检查这样的列表绝对不会受到伤害。然而，这些表格本质上只能包含可能适用于或不适用于特定项目和特定类别的概括。但是你显然有经验和思维方式为你的特定单位找到好的测试用例： - ）