【问题标题】:How should I implement this specflow step?我应该如何实现这个specflow步骤?
【发布时间】:2011-03-20 02:15:45
【问题描述】:

好的,我决定尝试从头到尾掌握整个 TDD 流程。

我正在用 ASP.NET MVC 2 应用程序编写一个简单的博客,并开始进行验收测试,以在我实现它们时测试我的功能。我使用 SpecFlow 作为我的 BDD/ATDD 框架。

我一直在阅读“Growing Object Orientated Systems Guided by Tests”,这就是为什么我要这样开始。

我将在书中描述为迭代零的点,我正在创建“行走的骨架”

我决定将登录过程作为“测试系统所有组件的最薄功能部分”开始。在这种情况下,网站本身和数据库。

所以我写了一篇详细介绍登录的故事,我写的第一个场景是成功登录。

上述场景中的一个给定是

"Given there is a registered user with the username 'TestUser' and password 'TestPassword'"

但是,我不确定如何实施此步骤。

显然,这意味着数据库中需要有一个具有给定凭据的用户。但是,就像一个优秀的小程序员一样,我希望密码以某种方式进行散列。

我想写一些可以为我插入的 DatabaseHelper 类。但是,这将包含散列代码来散列密码,然后应用程序本身将需要相同的散列代码,这似乎违反了 DRY。

所以这里真的有几个相关的问题:

  • 我正在努力完成这一步是否意味着我应该从其他地方开始?即使登录系统对站点的其他部分相当重要?也许它并不是测试网站和数据库的最薄的功能部分?
  • 如果你和我一样从同一个地方开始,你会怎么做?你不会担心 DRY 吗?由于验收测试通过浏览器在外部测试功能,我可能无能为力吗?

如果这个问题看起来有点模糊,我必须道歉,我没有人可以从这方面学习 TDD,这是我还没有那种“啊哈”时刻的范式转变之一。

提前致谢。

【问题讨论】:

    标签: database tdd bdd acceptance-testing specflow


    【解决方案1】:

    从没有此类注册用户的场景开始会更容易吗?系统也需要处理这个问题,它所做的事情可以在没有任何其他内容的情况下编写,只需要一个为数据库显示“没有这样的用户”的存根。

    【讨论】:

      【解决方案2】:

      如果您正在做 BDD,我是否建议不要从测试所有组件的最薄切片开始,而是从测试 风险最高 组件的最薄切片开始?

      假设任何有权访问系统的用户都已登录。登录并不是完全有风险的。之前已经完成了 15,000 次。

      硬编码要开始的数据。从数据库中获取数据也不是很冒险。如果您能获得一些真实的数据示例,您可以稍后再编写代码而不影响场景。

      找出您最不了解系统的哪些部分。创建场景并围绕系统的这些部分进行对话。您不必从一开始就扩展系统 - 您可以选择任何您喜欢的点!系统的哪些部分让你最不舒服?哪些部分让您的利益相关者最不舒服?

      这些可能会导致您的项目成功或失败。登录可以稍后进行,当您开始编写代码时,您将拥有一些人们想要登录的真正价值for

      【讨论】:

      • 这个项目是我自己的练习。不幸的是,系统让我感到不舒服的是测试。但是,你说得对,我可能应该从更有价值的东西开始。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2015-09-11
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2011-06-07
      • 1970-01-01
      相关资源
      最近更新 更多