我应该如何实现这个specflow步骤？
好的，我决定尝试从头到尾掌握整个 TDD 流程。
我正在 ASP.NET MVC 2 应用程序中编写一个简单的博客，并开始进行验收测试，以在实现它们时测试我的功能。我使用 SpecFlow 作为我的 BDD/ATDD 框架。
我一直在阅读“由测试引导的增长面向对象的系统”，这就是为什么我已经开始了。
我将在书中被描述为迭代零，在那里我正在创建“行走的骨架”，
我决定从登录过程开始，作为我的“测试系统所有组件的最薄的功能部分”。在本例中，是网站本身和数据库。
所以我写了一个详细描述登录的故事，我写的第一个场景是成功登录。
上述场景中的一个给定条件是
"Given there is a registered user with the username 'TestUser' and password 'TestPassword'"
但是我不确定如何实施此步骤。
显然，这意味着数据库中需要有一个具有给定凭据的用户。然而，就像一个优秀的小程序员一样，我希望密码以某种方式进行哈希处理。
我想编写某种 DatabaseHelper 类来为我插入它。然而，这将包含散列密码的散列代码，然后应用程序本身将需要相同的散列代码，这似乎违反了 DRY。
所以这里确实有几个相关的问题：
- 我在这一步中挣扎的事实是否意味着我应该从其他地方开始？即使登录系统对于网站的其他部分相当重要？也许这并不是测试网站和数据库的最薄的功能部分？
- 如果你和我从同一个地方开始，你会怎么做？你还不担心DRY吗？由于验收测试通过浏览器在外部测试功能，也许我无能为力？
如果这个问题看起来有些模糊，我必须道歉，我没有人从这方面学习 TDD，这是我还没有经历过“啊哈”时刻的范式转变之一。
提前致谢。
Okay, I've decided to try and get to grips with the whole TDD process from start to finish.
I'm writing a simple blog in ASP.NET MVC 2 Application and have started with doing acceptance tests to test my fetaures as I implement them. I'm using SpecFlow as my BDD/ATDD framework.
I've been reading "Growing Object Orientated Systems Guided by Tests" which is why I've started as I have.
I would be at the point described as iteration Zero in the book, where I'm creating the "Walking Skeleton"
I decided to start on the login process as my "thinnest slice of functionality that tests all components of the system". In this case, the website itself and the database.
So I wrote a story detailing logging in and the first scenario I'm writing is logging in successfully.
One of the givens in the said scenario is
"Given there is a registered user with the username 'TestUser' and password 'TestPassword'"
However I'm unsure how I would go implementing this step.
Obviously this means there needs to be a user in the database with the given credentials. However, like a good little programmer I'd want the password to be hashed in some way.
I thought of writing some sort DatabaseHelper class that can go insert that for me. However, that will contain the hashing code to hash the password, and then the application itself is going to require the same hashing code at that seems to violate DRY.
So really there are several related questions here:
- Does the fact that I'm struggling with this step mean I should start from somewhere else? Even though the Login system is fairly important to the rest of the site? Perhaps it's not really the thinnest slice of functionality that tests both the website and the database?
- If you'd start at the same place as I have, how would you do it? Would you not worry about DRY yet? As the Acceptance Tests test functionlity externally via the browser perhaps there's not much I can do?
I have to apologize if the question seems somewhat vague, I have no-one to learn TDD from this side, and it's one of those paradigm shifts that I've just not had that "ah-ha" moment yet.
Thanks in Advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您正在进行 BDD，我是否可以建议不要从测试所有组件的最薄切片开始，而是从测试风险最高组件的最薄切片开始？
假设有权访问系统的用户已经登录。登录并不完全有风险。以前已经做过15,000次了。
首先对数据进行硬编码。从数据库中获取数据也不是很有风险。如果您可以获得一些实际的数据示例，您可以稍后进行编码，而不会影响场景。
找出您对系统的哪些部分知之甚少。创建场景并围绕系统的这些部分进行对话。您不必从一开始就发展系统 - 您可以选择您喜欢的任何点！系统的哪些部分让您最不舒服？哪些方面让您的利益相关者最不舒服？
这些可能会导致您的项目成功或失败。登录可以稍后进行，当您开始编写代码时，您将获得人们想要登录的一些实际价值。。
If you're doing BDD, may I suggest starting not with the thinnest slice that tests all components, but instead, the thinnest slice that tests the riskiest components?
Assume that whichever user has access to the system is already logged in. Logging in isn't exactly risky. It's been done 15,000 times before.
Hard-code the data to start with. Getting data out of a database isn't very risky either. You can code this later without affecting the scenarios, if you can get some realistic examples of data.
Work out which bits of the system you know least about. Create the scenarios and have conversations around those bits of the system. You don't have to grow the system from the beginning - you can pick any point you like! Which bits of the system make you most uncomfortable? Which bits make your stakeholders most uncomfortable?
Those are probably the bits which will cause your project to succeed or fail. Logging in can come later, and by the time you come to code it, you'll have some real value that people want to log in for.
从没有这样的注册用户的场景入手会不会更容易一些？系统也需要处理这个问题，并且它所做的事情可以在没有任何东西的情况下编写，只需要一个存根来表示数据库“没有这样的用户”。
Would it be easier to start with the scenario that there is no such registered user? The system needs to handle that, too, and what it does can be written without anything more than a stub that says "no such user" for the database.