我经常遇到这个问题,我不知道如何克服这个障碍.我真的想开始学习和应用测试驱动开发(或BDD,或其他),但似乎我想要应用的每个应用程序,它几乎只是标准的数据库CRUD的东西,我不知道如何去应用它.除了被持久化到数据库之外,这些对象几乎不做任何事情; 没有需要测试的复杂逻辑.有一个网关,我最终需要测试第三方服务,但我想首先完成应用程序的核心.
每当我尝试编写测试时,我最终只会测试我可能不应该首先测试的基本内容(例如getter/setter),但它看起来不像对象有其他任何东西.我想我可以测试持久性,但这对我来说似乎永远不对,因为你不应该真的打到数据库,但如果你把它嘲笑,那么你真的没有测试任何东西,因为你控制了吐回来的数据; 就像我已经看到很多例子,其中有一个模拟存储库,通过循环和创建已知值列表来模拟数据库,并且测试验证"存储库"可以撤回某个值......我是没有看到这样的测试点,因为"存储库"当然会返回该值; 它在课堂上硬编码!好吧,我从纯TDD的角度看待它(也就是说你需要测试一下你的存储库需要一个GetCustomerByName方法或其他什么才能编写方法本身),但这看起来好像遵循了教条,除了它的"方式" - 除了证明方法合理之外,测试似乎没有做任何有用的事情.
我想错了吗？
例如,运行一次轧机联系管理应用程序.我们有联系人,让我们说我们可以向联系人发送消息.因此,我们有两个实体:Contact和Message每个实体具有共同的属性(例如,名字,姓氏,联系电子邮件,主题和正文以及消息的日期).如果这些对象都没有任何实际行为或需要执行任何逻辑,那么在设计这样的应用程序时如何应用TDD？该应用程序的唯一目的基本上是拉出联系人列表并在页面上显示它们,显示表单以发送消息等.我在这里没有看到任何有用的测试 - 我可以想到一些测试,但它们几乎是为了说"看,我有测试!"的测试.而不是实际测试某种逻辑(虽然Ruby on Rails很好地利用它,我并不认为测试验证是一个"有用的"测试,因为它应该是框架为你照顾的东西)
S.L*_*ott 14
"该应用程序的唯一目的基本上是提取联系人列表"
好的.测试一下."拉"是什么意思？这听起来像"逻辑".
"在页面上显示它们"
好的.测试一下.正确的显示？那里有什么？
"显示表单以发送消息"
好的.测试一下.正确的领域？输入的验证都有效吗？
"之类的."
好的.测试一下.查询是否有效？找到合适的数据？显示正确的数据？验证输入？为无效输入生成正确的错误消息？
我正在研究纯CRUD应用程序但是我看到了单元测试用例的很多好处(注意 - 我没说TDD)
我首先编写代码,然后编写测试用例 - 但是从来没有分开 - 尽快
我还测试了CRUD操作 - 对数据库的持久性.
当我完成持久性 - 并转移到UI层 - 我将有相当大的信心,我的服务\持久层是好的 - 然后我可以在那一刻专注于UI.
所以恕我直言 - TDD \单元测试总是有好处(无论你怎么称呼它取决于你对它的看法有多么极端) - 即使对于CRUD应用程序你只需要为你的应用程序找到合适的策略
只是使用常识....你会没事的.
我觉得我们将TDD与单元测试混淆了.
单元测试是测试行为单元的特定测试.这些测试通常包含在集成构建中.S.Lott为这些类型的测试描述了一些优秀的候选人.
TDD用于设计.我经常发现,当我使用TDD时,我写的测试要么被丢弃,要么演变为单元测试.这背后的原因是当我在做TDD时我正在测试我的设计,而我正在设计我的应用程序,类,方法,域等...
为了回应您的情况,我同意S.Lott所暗示的是,您需要的是一套单元测试来测试应用程序中的特定行为.
| 归档时间： |
|
| 查看次数： |
6749 次 |
| 最近记录： |