我正在寻找以下规则：
如果符合以下条件，则测试不是单元测试：
还有什么？
答案 0 :(得分：66)
请参阅Michael Feathers' definition
如果出现以下情况，则测试不是单元测试：
- 与数据库对话
- 通过网络进行通信
- 它触及文件系统
- 它不能与任何其他单元测试同时运行
- 您必须对您的环境做特殊事情（例如编辑 配置文件）来运行它。
答案 1 :(得分：34)
如果测试不是测试单元，则测试不是单元测试。
说真的，这就是它的全部内容。
单元测试中“单元”的概念没有明确定义，实际上，到目前为止我发现的最佳定义实际上并不是定义，因为它是循环的：单元测试中的单元是最小的可以孤立地测试的东西。
这为您提供了两个检查点：它是单独测试的吗？它是最小的东西吗？
请注意，这些都与上下文有关。在一种情况下可能是最小的可能（例如，整个对象）可能在另一种情况下只是一个单一方法的一小部分。在一种情况下，隔离可能在另一种情况下（例如，在内存管理的语言中，您从不与垃圾收集器隔离运行，并且大部分时间是无关紧要的，但有时它可能不是）。
答案 2 :(得分：7)
它没有断言，并且不期望抛出异常。
答案 3 :(得分：6)
很难......
对我来说，单元测试会验证隔离中的一个特定逻辑。意思是，我采取一些逻辑，从其余部分中提取它（如果有必要通过模拟依赖关系）并通过探索不同类型的可能控制流来测试该逻辑 - 一个单元（整体）。
但另一方面......我们总能100％说正确或不正确吗？不要成为哲学，但是 - 在他的帖子中也是Michael says：
执行these things的测试也不错。 通常他们值得写作，他们 可以写在单元测试工具中。 但是，重要的是能够 将它们与真正的单元测试区分开来 我们可以保留一组测试 每当我们制作时，我们都可以快速奔跑 变化。
那么为什么我不应该编写一个单元测试，通过从我的测试文件夹中的文件系统访问一些虚拟文件来验证解析例如xls文件的逻辑（就像MS测试允许使用DeploymentItem一样）？
当然 - 如上所述 - 我们应该将这些测试与其他测试分开（可能在JUnit中的单独测试套件中）。但是我觉得如果他觉得把它们放在那里也应该写下那些测试......然后再一次记住单元测试应该只是单独测试一块。
在我看来，最重要的是这些测试运行速度快，不需要太长时间。它们可以反复运行。
答案 4 :(得分：6)
在以下情况下，测试不是单元测试：
良好单元测试的核对表：
一些更好的实践（没有特别重要的顺序）：
这是我从Roy Osherove的书中提取的知识的一部分 - The Art of Unit Testing
答案 5 :(得分：2)
跨多个可能失败的单元实施测试不是单元测试。
答案 6 :(得分：1)
错综复杂的问题。
假设我要编写一些业务逻辑，并且所有业务逻辑都需要通过某种形式的DAL获取数据。
假设为了测试目的，我模拟了DAL单元（通过创建“mockingbirds”）。
但那些模仿鸟当然是附加单位本身。因此，即使使用模拟，当我想要对我的业务逻辑模块进行单元测试时，似乎我仍然必然会违反“没有其他单位参与”的想法。
当然，众所周知，“为DAL创建模拟鸟”可能会使您的模拟鸟在DAL的某个特定方面偏离的计数无效。
结论：对任何类型的DAL，问号依赖的业务模块进行“真正的单元测试”是不可能的？
Corrolary：唯一能够（“真正”！）单元测试的是DAL本身，问号？
证据的证据：鉴于“DAL”通常是ORM或某些DBMS的DML，并且考虑到这些产品通常作为“经过验证的技术”购买，那么做什么的附加价值是什么？单元测试什么，问号？
答案 7 :(得分：0)
在测试是否是单元测试后，下一个问题是good unit test？