TDD,您寻找好的测试的技巧是什么?
-
03-07-2019 - |
题
我正在使用 Linq to Sql 作为我的数据层编写一个简单的 Web 应用程序,因为我非常喜欢 Linq2Sql。我最近阅读了一些有关 DDD 和 TDD 的内容,并想尝试一下。
首先,也是最重要的一点是,Linq2Sql 和 DDD 的配合不太好。我的另一个问题是寻找测试,实际上我发现很难定义好的测试,所以我想问,发现好的测试用例的最佳技术是什么。
解决方案
测试用例发现与其说是一门科学,不如说是一门艺术。然而,简单的指导方针包括:
- 您知道脆弱/脆弱/可能损坏的代码
- 遵循用户场景(您的用户将做什么)并查看它将如何影响您的代码(通常这意味着对其进行调试,有时进行分析,有时仅意味着考虑场景) - 代码中的任何点都会受到影响对于用户来说,这些是编写测试的最高优先级。
- 在您自己的开发过程中,您运行的测试会导致您发现错误 - 编写测试以避免代码再次出现相同的行为。
有几本书介绍如何编写测试用例,但是除非您在需要记录测试用例的大型组织中工作,否则最好的选择是考虑代码中您不喜欢的所有部分(这些部分不是不是“纯粹的”)并确保您可以彻底测试这些模块。
其他提示
嗯,按照TDD的标准解释,测试驱动您的开发。所以,从本质上讲,你从测试开始。它将失败,您将编写代码,直到该测试通过。所以它是由你的要求驱动的,但是你要去收集它们。您决定您的应用程序/功能需要做什么,编写测试,然后编码直到它通过。当然,还有很多其他技术,但这只是关于TDD世界中通常所想的内容的简短陈述。
<强>思即可。阅读代码。问自己:例如这个指针在这里永远不会是NULL吗?如果在初始化之前调用此方法会发生什么?
不要做出假设,例如“此文件将始终存在”。测试。
考虑边缘情况,边界,负值,溢出......
Bug通常按群集分组。当你找到一个时环顾四周。还要在其他位置查找相同类型的错误。
将您的想法设定为测试的实际目标:查找错误。
想象一下会导致你的程序失败的事情,具有创造性。
您的测试必须找到错误,而不是确认您的程序是否正常。
我经常为第三方API编写测试。这样,当API更新时,我知道我是否会破坏。
我认为这是一种有用的技术:
参考:Lisa(Ling)Liu,Bertrand Meyer和 Bernd Schoeller,使用契约和布尔查询来改进 在 TAP:测试的程序中,自动测试生成的质量 和证据,苏黎世联邦理工学院,2007年2月5日至6日,编辑。 Yuri Gurevich和 Bertrand Meyer,计算机科学讲义,Springer- Verlag,2007。