Outdated egg!

This is an egg for CHICKEN 4, the unsupported old release. You're almost certainly looking for the CHICKEN 5 version of this egg, if it exists.

If it does not exist, there may be equivalent functionality provided by another egg; have a look at the egg index. Otherwise, please consider porting this egg to the current version of CHICKEN.


  1. Outdated egg!
  2. Chickumber
    1. Introduction
    2. Examples
    3. Using the chickumber-server
    4. Writing step-definitions
      1. Maintaining State
      2. Hooks


This is an implementation of a wire-server for cucumber. It allows you to develop and run your acceptance tests within cucumber by defining the steps in scheme.

I provides the chickumber-server application as well as an api that allows you do define your steps.

For those of you, who don't know cucumber yet, please check out Cucumber, for an overview.


See chickumber-examples

Using the chickumber-server

The following assumes that you have a working-directory with a standard-layout. That means you have the subdirectories features, features/step_definitions features/support.

To create the directory structure just issue

mkdir -p features/{step_definitions,support}

First make sure that you let cucumber know that you want to use the wire-server. To do so, create a file features/step_definitions/chickumber.wire with the following content:

host: localhost
port: 61616

Now start your chickumber-server with the following command:

$ chickumber-server -f test -v 

This will invoke the server and load the test egg as the testing-framework that is used inside the step-definitions.

By default the server loads all scheme files in features/support and features/step_definitions. The files in features/support are loaded before the step_definitions. Also it does reload these files if you change them later. So you don't have to restart the server all the time.

Now you're server is up an running and you can run cucumber on your features.


$ cucumber --tags @chickumber 

Writing step-definitions

Chickumber let's you write your step-definitions in scheme. The easiest way to show you, how this works, is by example. ( You might as well want to have a look at the example that comes with this egg. )

(Given #/^I am pending/ ()
  (pending "I am pending at the moment"))

(Given #/^I am not yet playing$/ () #t)

(Then #/^I should see "([^"]+)"$/ (message)
   (test #t (number? (substring-index message (get-output-string ($ 'mock-io))))))

This is essentially the same as you would do in ruby. You define a regular expression on the step and fill in the code that does the setup and assertions.

[syntax] (Given rx (matches ...) code ...)
[syntax] (When rx (matches ...) code ...)
[syntax] (Then rx (matches ...) code ...)
[procedure] (pending #!optional (message ""))

This stops the execution of the step and marks it as pending, optionally passing message.

Maintaining State

It is a common case to use the Given-clause to setup a well defined state of the world that the Whens and Thens can work with. Chickumber has support for a simple mechanism to maintain state.

It provides the following constructs:

[procedure] ($ key #!key (default #f))

It retrieves the value of key if has been set or default otherwise. The procedure supports generilized setters so that you can do:

(set! ($ 'some-key) 'value)

You can define Before- and After-hooks that are execute before/after each step-definition. At the moment they can not handle tags though.

[syntax] (Before () code more-code ...)

This will execute the code before each step.

[syntax] (After () code more-code ...)

This will execute the code after each step.