A couple of people have recently written asking for advice on how to start writing scenarios. In both instances, they have started by logging in, because “that’s what the users do first”.
If you’re doing BDD, may I suggest starting not with the scenario that describes the entire user journey, but instead, the scenario that describes the riskiest bits of the journey?
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.
Liz Keogh, lunivore 
This fits well with the definition of TDD I have adopted (thanks mainly to Andy Glover). Not necessarily “write tests first”, which is impossible to do with inherited code, but “make sure that your riskiest code has adequate test coverage within a reasonable amount of time, for values of ‘riskiest’, ‘adequate’, and ‘reasonable’ that are appropriate to the situation.” Riskiest usually turns out to mean most complex, most business-critical, or easiest to get wrong (not *quite* the same thing as most complex).
Crystal calls this approach “Walking Skeleton”. The idea is to go end-to-end early to ensure you can overcome technical risks to architecture. It is worth remembering that you want incremental not iterative re-architecture i.e. each iteration adds more flesh on the bones, but does not fundamentally change the shape of the skeleton. This gives us both ‘early-learning’ a key win for agile over waterfall which is ‘late-learning’ (you don’t find out this does not work until late in the project). It also enables you to control scope because you have a working if bare system from early on.
http://alistair.cockburn.us/Walking+skeleton
On the second day of my TDD class I usually play the following trick on the participants:
I give them a simple application to write using TDD. I ask them to implement a short list of features (They have between 3-4 hours to finish, but they aren’t expected to finish all of the features.) Generally, the fourth or fifth story on the list is one that implies there are multiple users (Though I never ask for a login explicitly.)
Inevitably, some pair will implement the login first. I have very deliberately communicated that I want these features and that the list is in priority order. The only feature which might require a login (And it’s not entirely self-evident that it does) is near the bottom of the list. This leads to a very interesting conversation.
The real world works just like this. Customers tend to assume that login is not the most interesting part of the problem because they have seen us do it before and reasonably well. There are other things that the app does that are more interesting and/or risky. They want those things first, and we ought to be able to accommodate them.
Pingback: Twitter Summary July 2010 « CDS 43
On the other hand, logging in is, in many instances, an essential prerequisite for anything else you might do with the system. From a security point of view, then, it’s the most obvious attack vector. Testing that it works as intended should be high on your priority list if you hold user data, which you do if you require users to log in.
Not that testing it will necessarily improve security, but that’s a different topic…