How should I implement this specflow step?

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 ca开发者_运维百科n 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.

---

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.