Recently I was working with Behavior Driven Development approach in Rails using RSpec and Capybara. Everything looks okay and it even can speed up whole planning-development bridge in my work (by defining closely behavior of app than usual specification documentation). Anyway, here is my though: is BDD so cool why there is no version control workflow for it? Here is my thought:
Rationale
BDD usually contains two things of each feature:
- described test
- implementation
That means there are two entities of each feature – dependent to build full-feature, but separated physically. Moreover, the standard procedure (also known as cycle) of building each feature contains:
- Write behavioral tests
- Write implementation
Although there is no implementation of this proccess in version control, I question the Internet why and there wasn’t any response.
Proposition
Assume that there are three types of branches:
- master (or some kind of dev branch)
- wish
- implementation (those two will be described later)
Wish
BDD covers planning process by adding some tests of particular feature before writing code and let them fail. Why just separate this process in branch and tell that is wish how software should work. For example, there is a wish_A branch with particular (based on the RSpec) feature test. This branch is just for developing the test scenario for feature at once.
Implementation
It is natural that each wish should become working code eventually. So this is the way of implementing behavior – by branching wish_A and implementing there a working code. By the last word of lifecycle, the implementation branch is merged into dev or master or any opther version/codename branch.
Issues
Dependency issues
Each wish branch can be depends on many other wishes. Assume that:
A_wishandB_wishare basic, independent featuresAB_wishrequiresA_wishandB_wishfuctionallity
I can’t figure what problems might occur after branching from one of A or B and merging another. Implementation of those wishes should be similar – with some conflicts or other problems of code’s tech nature.
Question
I can’t find why this is not implemented by some software-development approach or why it won’t work with BDD. Are there particular reasons for not doing some kind of generic approach?
Generally speaking, a software project is a collection of code, data and tests. Typically these should all live in the same repository. Using BDD or TDD means simply to check in (or at least develop) your tests before developing your code. It doesn’t have to be any more complicated than that.
So, the reason why no specialized workflow has been created is because no specialized workflow is required. You create a branch for the new feature, you create some tests and check them in to that branch, then you write the code and check it in to the same branch.
Honestly, this doesn’t sound like something your VCS should care about. Your VCS should only care about the storage of, revisions to and merging of changes to your source code. The idea of a wishlist of features doesn’t fit with any of those things.
A wishlist of features is the domain of a product backlog (or something similar). Stakeholders can file new items for the wishlist, which are in turn fleshed out by the product owner. Part of that fleshing out might be the writing (and negotiation with devs) of the text for the BDD spec.
When a wishlist item is ready to be worked on, developers can take whatever workflow they like to implement it. When there is code to be stored and revisioned, then your VCS comes in to play.
1