Project

cukeq

0.0
No commit activity in last 3 years
No release in over 3 years
Cucumber features distributed using AMQP.
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
 Dependencies

Development

Runtime

>= 0
>= 0
>= 0
>= 0
 Project Readme

cukeq¶ ↑

This code is not in a usable state yet, contributions welcome!

This project will some time in the future provide a simple way of distributing Cucumber features across machines and collect the results.

Dependencies¶ ↑

You need to have an AMQP broker (like RabbitMQ) installed and running:

$ brew install rabbitmq
$ ruby -rubygems bin/cukeq setup
$ rabbitmq-server

If you want to use CukeQ with Subversion, you’ll need to install the Ruby bindings:

$ sudo apt-get install libsvn-ruby

Interface¶ ↑

$ cukeq master --broker URI --report-to URI --scm URI
$ cukeq slave --broker URI

Master¶ ↑

  1. REST service to trigger runs, payload:

{:features => ["file:line", "file:line", ...]}
  1. Update from SCM.

  2. Call Cucumber to get «exploded scenarios» (JSON) - (shell out to cucumber with custom formatter + –dry-run ??).

  3. Create JSON payload

[
  {
    :run_id => id,
    :scm    => {:revision => 1234, :url => "git://..."}
    :exploded_scenario => ast(?)
  },
...
]
  1. Put payload on jobs queue.

  2. Pull step result from result queue.

  3. POST step result to –report-to URL, and/or let several reporters register themselves with the Master webapp (webhookish)

Slave¶ ↑

  1. Pull job from job queue.

  2. If job revision != last revision

    * Update/checkout from SCM.
    * Restart Cucumber process with updated code files.
  3. Invoke steps (through wire protocol?)

  4. Put step/scenario/unit (undecided) result on result queue.

Other¶ ↑

  • All parsing is done on the master - the slave shouldn’t have to parse .feature files.

  • The slave should be able to invoke cucumber steps implemented in any of the supported languages

  • Need a (separate?) webapp to select which features to run and show the results as the step results come in. (a –report-to recipient)

  • Should also be able to trigger runs from command line (‘cukeq-runner file:line file:line`, prints `app/runs/«run id»`)

Note on Patches/Pull Requests¶ ↑

  • Fork the project.

  • Make your feature addition or bug fix.

  • Add tests for it. This is important so I don’t break it in a future version unintentionally.

  • Commit, do not mess with rakefile, version, or history. (if you want to have your own version, that is fine but bump version in a commit by itself I can ignore when I pull)

  • Send me a pull request. Bonus points for topic branches.

Copyright © 2009 Jari Bakken. See LICENSE for details.