单元测试 – 是否有过多的单元测试？
|
我不是全新的单元测试的概念，但同时我还没有掌握它们。
最近我一直在编写单元测试的一个问题是使用TDD方法写我的代码是：我应该在什么级别进行测试？ 有时我想知道我是否过度使用单元测试。 开发商在什么时候停止编写单元测试并完成实际工作？ 在人们认为我反对使用TDD之前，我可能需要澄清这个问题 我正在努力的是我的测试的粒度…. >当我的应用程序有一个配置文件我做 我想能够使用我的单元测试来验证我的应用程序的行为…但我不太确定在哪里停止。是否有可能编写太简单的测试？
[更新：]在TDD ByExample – Pg194中找到了这个问题的简明扼要的答案。
[/更新] 我认为在当前时代普遍存在的问题是缺乏单元测试…没有过多的测试。我想我会看到你在做什么..我不会把它作为过度的单元测试，而是…不太了解你在哪里集中精力。 所以回答你的问题..一些指导方针。 >如果你遵循TDD，你将不会有单元测试没有覆盖的代码。因为你只写(最小)代码来传递失败的单元测试，而不是更多。推论：每个问题都应该失败，单位测试会明确指出缺陷的位置。同样的缺陷不应该导致数十个UT同时断开>不要测试你没有写的代码。一个推论是：你不要测试框架代码(比如从app.config文件中读取值)你只是认为它是有效的。你有多少次框架代码破裂？接近零。>如果有疑问，请考虑失败的可能性，并对自动测试案例的编写成本进行权衡。为访问者编写测试用例/重复数据集测试。>解决痛苦。如果你发现你在某个地区有周期性的问题，可以把它放在一个测试工具下，而不是花时间为你所知道的领域写出冗余测试。例如第三方/团队图书馆不断在界面上打破。这样做不行。模特不会抓住它。有一个回归类型套件使用真正的协作者，并运行一些健全测试来验证链接，如果你知道它是一个问题的孩子。 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |