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

Question

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

后，如果你有这些太连接到他们正在测试的代码错误

Answer 1

写作考试的例子一些示例代码。在我依赖语义耦合以及我只是假设为班级工作的情况下，情况尤其如此。

Answer 2

依赖于某些实现细节，这些细节不属于测试功能的一部分，并且可能在以后的开发中发生变化。
有时候，这些假设太难分解，或者太过于禁止考虑和变化。

Answer 3

缺乏报道 - 我很少测试我第一次传球时的所有情况。

Answer 4

在一次测试中测试太多。我的单元测试通常不会将自己局限于被测方法，而是更多地体现了集成测试的特点。

Answer 5

留下了一些小细节（例如，一个十六进制十进制功能在单元测试并没有在它的任何信件...）

Answer 6

嗯，我有时错过了扑灭[测试] C＃属性，并且测试甚至不会运行:)

Answer 7

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

Answer 8

忘记在双比较中舍入误差允许值可能是我最大也是最烦人的错误。

Answer 9

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

我倾向于测试编写单元测试时出现的代码。也就是说，我将编写一系列测试，它们的覆盖范围非常高，并且测试了大部分代码，但未能覆盖代码未涵盖的基本错误条件。

Answer 10

根本不写。

Answer 11

不先写他们（即不打算在测试驱动路线）

Answer 12

制作不使用模拟对象或框架紧密耦合的两个积分点。

Answer 13

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

Answer 14

没有得到测试夹具整洁，整齐不够 - 所以写测试是难度比它应该是。

Answer 15

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

我发现在一个测试中测试3-4层代码的测试没有扎根于人们理解的概念，通常会导致测试成为维护的负担，并使人们失望并被自动关闭测试。

Answer 16

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

测试成功，所以我感觉很好。事情正在起作用。我转向别的东西。结果发现有一个未经测试的角落案例。

Answer 17

测试依赖于您碰巧正在操作的操作系统的怪癖，或者以前测试的无意的副作用。