编写单元测试时最常犯的错误是什么？

Question

在编写单元测试时，您最常犯的错误是什么？耦合？缺乏凝聚力？尝试一次测试太多功能？没有测试足够的功能？

如果您有错误的示例，请发布一些示例代码

Answer 1

根本不写。

Answer 2

在一次测试中测试太多。我的单元测试通常不仅仅局限于集成测试的特性，而是将自己局限于测试中的方法。

Answer 3

测试 存在的代码，而不是应存在的代码。

我倾向于测试编写单元测试时存在的代码。也就是说，我将编写一系列具有极高覆盖率的测试并测试大多数现有代码，但是错过了代码未涵盖的基本错误条件。

Answer 4

编写与他们正在测试的代码过于耦合的测试。在我依赖语义耦合和我假设为类工作的事情时，尤其如此。

Answer 5

依赖于某些实施细节，这些细节不是测试功能的一部分，可能会在以后的开发中发生变化 有时这些假设太难以分解或太过于难以考虑和变化。

Answer 6

缺乏报道 - 我很少测试我第一次通过的所有情况。

Answer 7

忘记在双重比较中加入舍入错误允许可能是我最大和最烦人的错误。

Answer 8

仅使用一些随机值进行测试，而不是使用等价分区和边界值分析进行测试。

Answer 9

不首先编写它们（即不进入测试驱动路线）

Answer 10

通过不使用模拟对象或框架使两个集成点紧密耦合。

Answer 11

没有让测试装置整洁干净 - 所以编写测试比应该更难。

Answer 12

编写既不是单元测试（仅测试特定方法）也不是验收测试（从用户角度测试）的测试。

我发现在一次测试中测试3-4层代码的测试不是基于商业人士理解的概念，通常导致测试成为维护的负担，让人们感到失望并被自动化测试关闭。

Answer 13

好吧，我有时会错过推出[Test] C＃属性，测试甚至无法运行：）

Answer 14

省略一些小细节（例如十六进制到十进制函数，其中单元测试中没有任何字母......）

Answer 15

http://msdn.microsoft.com/en-us/magazine/cc163665.aspx

Answer 16

仅部分代码覆盖的单元测试。

测试成功，所以我感觉很好。事情很有效。我继续做其他事情。原来是一个未经测试的角落案例。

Answer 17

测试取决于您碰巧遇到的操作系统的怪癖，或者是之前测试的无意识副作用。