You are looking at historical revision 23761 of this page. It may differ significantly from its current revision.
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.
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.
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
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.
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.