Okay, I have made the decision to get a handle on the entire TDD process from beginning to end.
I am writing an easy blog in ASP.Internet MVC 2 Application and also have began with doing acceptance tests to check my fetaures when i implement them. I am using SpecFlow as my BDD/ATDD framework.
I have been reading through "Growing Object Orientated Systems Guided by Tests" and that's why I have began when i have.
I'd attend the purpose referred to as iteration Zero within the book, where I am creating the "Walking Skeleton"
I made the decision to begin around the login process as my "slimest slice of functionality that tests all aspects of the machineInch. Within this situation, the web site itself and also the database.
And So I authored a tale detailing signing in and also the first scenario I am writing is signing in effectively.
Among the givens within the stated scenario is
"Given there is a registered user with the username 'TestUser' and password 'TestPassword'"
However I am unsure the way i would go applying this task.
Clearly what this means is there should be a person within the database using the given qualifications. However, just like a good little programmer I'd want the password to become hashed in some manner.
I figured of writing some kind DatabaseHelper class that may go place that for me personally. However, which will retain the hashing code to hash the password, and so the application itself will require same hashing code at this appears to violate DRY.
So really you will find several related questions here:
- Does the truth that I am battling with this particular step mean I ought to begin with elsewhere? Despite the fact that the Login product is fairly vital that you the relaxation from the site? Possibly it isn't truly the slimest slice of functionality that tests both website and also the database?
- If you would start at the same location when i have, how does one get it done? Can you not be worried about DRY yet? Because the Acceptance Tests test functionlity externally through the browser possibly there isn't much I'm able to do?
I must apologize when the question appears somewhat vague, I've no-someone to learn TDD out of this side, and it is among individuals paradigm changes that I have simply not had that "ah-'" moment yet.
Thanks ahead of time.
If you are doing BDD, may I would recommend beginning avoid the slimest slice that tests all components, but rather, the slimest slice that tests the riskiest components?
Think that whichever user can access the machine has already been drenched in. Signing in is not exactly dangerous. It has been done 15,000 occasions before.
Hard-code the information to begin with. Getting data from a database is not very dangerous either. You are able to code this later without having affected the situations, if you're able to acquire some realistic good examples of information.
Figure out which items of the machine you realize least about. Produce the situations and also have conversations around individuals items of the machine. It's not necessary to grow the machine right from the start - you are able to pick any point you want! Which items of the machine cause you to most uncomfortable? Which bits build your stakeholders most uncomfortable?
Individuals are most likely the bits that will cause any project to achieve success or fail. Signing in may come later, and when you arrived at code it, you will have some real value that individuals wish to sign in for.
Will it be simpler to begin with the scenario that there's no such registered user? The machine must handle that, too, and what it really does could be written without anything further than a stub that states "no such user" for that database.