[rspec-users] [cucumber] Cucumber and CI

Zach Dennis zach.dennis at gmail.com
Sun Feb 22 16:07:27 EST 2009


On Sun, Feb 22, 2009 at 2:47 PM, Yi Wen <hayafirst at 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


More information about the rspec-users mailing list