0

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:

  1. Write behavioral tests
  2. 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_wish and B_wish are basic, independent features
  • AB_wish requires A_wish and B_wish fuctionallity

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?

2 Answers 2

3

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.

2

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
  • Fully agree that it is not VCS resposibility. But the question is what if?. If VCS, documentation and wishlist can shrink into one tool why it is not a good way?
    – Dawid Pura
    Commented May 11, 2015 at 16:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.