On Sun, Feb 22, 2009 at 2:47 PM, Yi Wen <hayafi...@gmail.com> wrote: > The rhythm for wrking with cucumber advertised by http://cukes.info/ is to > write tests that fails first, then code that fixes it. Now my question is, > what is the implication when combine this with Continuous Integration? > > We all know when we do TDD/BDD in unit level, one test can be fixed fairly > quick in a coupe minutes and we can check in and kick off a build. It is a > ideal scene for doing CI: frequent checkin and fast feedback on build > results. > > Cucumber, as far as my understanding goes, works on feature level. It could > take people days to finish a cucumber feature. In the meantime, the cucumber > test remains broken. What do we do then? We cannot check in any code because > that'll break the build. So we can only checkin code after several days? It > doesn't sound right to me. Any takes on this issue? Thanks in advance. >
I use git, create a new branch for a feature, and work in that branch while I'm implementing the feature. As I reach stable points in the feature (even though it may not be done) I will merge into master and push the changes. Usually at this point I've reached the end of a step definition so the next step isn't failing, it's just pending. If unable to reach a stable point to merge back into master one option is to call "pending" inside of the step definition you were last working on, so CI doesn't use that to signify that someone broke the build. This lets you merge back into master and push. Most of the time I work in the feature branch, continually updating and rebasing as others push changes so I'm not out of sync, and then I merge back into master and push when the feature is either stable or done. I'm sure there are lots of ways to go about this though, -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
