Recently I have been trying to get more involved with agile process and BDD, while lots of documentation exists on some of the preferred frameworks such as Rspec and Cucumber, it can be very difficult to determine what may be the right or wrong way of going about it.
In my attempt at progressing my knowledge around the topic I decided to document my discoveries here so that others may benefit.
What is it?
Behavior driven development attempts to take the traditional approach we take to doing things and turn it on its head. Rather then thinking from the bottom we think from the top down. Who does this unit of functionality benefit? why does it benefit them? and how do they interact with it?
Answering these questions will help us to determine if a feature is needed and at what point in time.
How do I get started?
While lots of articles exist on setting up Cucumber and and Rspec and many examples exist for the cucumber feature syntax, none really guide you in the direction of where to begin. Ive found myself hung up running in circles, asking questions until I’m blue in the face with not one line of code written.
- What feature do I start first? possibly authentication?
- What constitutes a feature? “Manage users”? or just “Creating a user”?
lets try to answer some of these with the opinions I have developed.
What feature do I start first?
The answer to this question is almost so incredibly easy that you bypass it completely. Think about the problem BDD is meant to solve, we want to create “software that matters”. We want to spend our time working on the features that matter most, those that will ultimately make you money. So lets answer this question what is the primary goal of your product?
Lets take a hypothetical project, an issue tracker for example. Its primary purpose is to organize tickets. There is our answer the tickets.
Wait a minute
Now I bet your saying wait, hold on just a minute but I need users and possibly roles. My question to you is do you? is that really pertinent now? I don’t think it is, I used to be in same boat trying set up all this ground work authentication and authorization systems, but is it really needed? In the future maybe, with a different stakeholder. But for now can we organize tickets as a single user? sure we can yeah it may be a little hectic who created what ticket and who its assigned to, but that is exactly what this iterative development process is meant to solve. Lets worry about those details when we get to them and allow our features to drive the implementation.
What constitutes a feature
I’m sure there is a lot of debate on this topic, however I prefer to take the approach of thinking each individual task that a user wishes to perform as a feature. Rather then having a features/ directory containing a users.feature , projects.feature, etc.. I tend to think of those as a module and not really a feature so i prefer to break up my features by module then by feature features/projects/create_project.feature , features/users/destroy_user.feature. while this approach seems to generate more feature files with some being relatively small, I feel it gives me the proper organization and separation of features.
to be continued… I hope to do a follow up post with some demo code as I build out one of my projects.