David Chelimsky wrote:
On Thu, Aug 20, 2009 at 7:00 PM, Marcelo de Moraes
Serpa<celose...@gmail.com> wrote:
Hello list,
I'm working in a big project in the company I'm working on as a "BDD
tech lead", this means I'm leading the implementation of BDD in
ongoing projects, most of them did not use BDD from the start.
I implemented the policy of "Only commit if all your tests are
passing", this in all tests abstraction levels: From Cucumber features
, scenarios, steps and rspec specs.
The point of this rule is: "Never commit partial code". If it's not
done/fully working (as the feature/specs say it should), don't commit
it.
However, a co-worker of mine came to me and said that partial commits
are needed to share code. I don't agree with that, I think we can use
patches or branches to do that (like a development branch) but at
least one branch should have only stabe/deliverable code.
For patches, however, he mentioned that we might have conflicts/code
duplication, where the guy who shares the patches will have problems
later on when pulling from the server (he already had part of the code
that was committed).
What do you think? I'm looking for some enlightenment! Any
contributions welcome.
We use remote branches (we use git) to collaborate and share code that
isn't ready to be merged down to our mainline. Then when that branch is
ready to be merged down we use git rebase --interactive to squash all
the wip/garbage commits. This gives you the best of both worlds IMO.
Using rebase can be dangerous though as it rewrites the repo's history.
That means once someone rebases everyone will have to delete that branch
and pull it again if they want to continue working on it. That is why
we generally wait until the work on the branch is don't before we rebase.
My approach, which is not mine originally, nor very unique, is follows:
All developer specs (RSpec) should always be passing.
Previously passing customer specs should continue passing.
Customer specs for features in development are allowed to fail.
You can enforce those rules in a CI build in any number of ways.
Tagging features in development as @in_development, for example, and
not running those as part of the CI build, or running them separately
but allowing them to fail without considering the build a failed
build.
That all make sense?
Cucumber actually ships now with some additional rake tasks to help with
this:
rake cucumber # Alias for cucumber:ok
rake cucumber:all # Run all features
rake cucumber:ok # Run features that should pass
rake cucumber:wip # Run features that are being worked on
-Ben
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
