最近我一直在编写单元测试的一个问题是使用TDD方法写我的代码是：我应该在什么级别进行测试？
有时我想知道我是否过度使用单元测试。
开发商在什么时候停止编写单元测试并完成实际工作？
在人们认为我反对使用TDD之前，我可能需要澄清这个问题
我正在努力的是我的测试的粒度….
>当我的应用程序有一个配置文件我做
测试可以检索值
从文件？我倾向于是….但….
>然后我写一个
对每个可能的配置进行单元测试
将出现的价值？即检查它们是否存在…并且可以解析为正确的类型…
>当我的
应用程序会将错误写入日志，我需要
测试它是否能够写入
日志？然后我需要写
测试以验证条目是
实际上做了日志？
我想能够使用我的单元测试来验证我的应用程序的行为…但我不太确定在哪里停止。是否有可能编写太简单的测试？
The simple answer,supplied by Phlip
is,“Write tests until fear is
transformed into boredom.”
[/更新]
我认为在当前时代普遍存在的问题是缺乏单元测试…没有过多的测试。我想我会看到你在做什么..我不会把它作为过度的单元测试，而是…不太了解你在哪里集中精力。
所以回答你的问题..一些指导方针。
>如果你遵循TDD，你将不会有单元测试没有覆盖的代码。因为你只写(最小)代码来传递失败的单元测试，而不是更多。推论：每个问题都应该失败，单位测试会明确指出缺陷的位置。同样的缺陷不应该导致数十个UT同时断开>不要测试你没有写的代码。一个推论是：你不要测试框架代码(比如从app.config文件中读取值)你只是认为它是有效的。你有多少次框架代码破裂？接近零。>如果有疑问，请考虑失败的可能性，并对自动测试案例的编写成本进行权衡。为访问者编写测试用例/重复数据集测试。>解决痛苦。如果你发现你在某个地区有周期性的问题，可以把它放在一个测试工具下，而不是花时间为你所知道的领域写出冗余测试。例如第三方/团队图书馆不断在界面上打破。这样做不行。模特不会抓住它。有一个回归类型套件使用真正的协作者，并运行一些健全测试来验证链接，如果你知道它是一个问题的孩子。
