On 23/04/14 19:17, Atila Neves wrote:
Thanks. :)

The examples directory (which actually only contains one example) shows
what is the bare minimum needed. You need:

1. A file with the .wire extension with the host and port for cucumber
to connect to in features/step_definitions (just like the example).
Cucumber automatically finds this
2. An "app" D source file that tells the compiler which modules to look
for step definitions in at compile-time. These are passed in as
compile-time string parameters to cucumber.server.runCucumberServer
(look at examples/source/app.d)
3. Compile the server app with its dependencies by using dub or the
build system of choice
4. Run the server, run cucumber in another shell, marvel at the results :P

The only thing that may be confusing in the example directory is the
fact that the modules that app.d references are themselves in the
`tests` directory. The reason being that I actually use them for unit
tests too and as we all know, duplication is bad.

Aha, their they are. I didn't noticed the step definitions before. Especially confusing since you do have a step_definitions directory.

I expect to run the acceptance / feature tests from a shell script that
compiles and runs the server, runs cucumber then brings the server down.
Now that I think of it it should be possible to do that from Cucumber
itself by using `After` and `Before`. I had to do something like that
whilst bootstrapping the process and also for some tests I wrote for my
MQTT broker. I think this should work but I can't try it right now so
don't trust me:

     Before do
       @server = IO.popen("./your_server_name")
       Timeout.timeout(1) do
         while @socket.nil?
             @socket = TCPSocket.new('localhost', port)
           rescue Errno::ECONNREFUSED
             #keep trying until the server is up or we time out

     After do
       @socket.nil? or @socket.close
       if not @server.nil?
         Process.kill("INT", @server.pid)

The reason it should work is that Cucumber supports mixing step
definitions in Ruby and over the wire. Which is awesome.

Cool. Have you considered embedding Ruby in some executable and call the D functions from Ruby. To avoid the server and wire protocol.

/Jacob Carlborg

Reply via email to