www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Unencumbered V0.1.2: Write Cucumber step definitions in D

reply "Atila Neves" <atila.neves gmail.com> writes:
Like testing with Cucumber? Wish you could call native D code 
with it? Now you can!

http://code.dlang.org/packages/unencumbered
https://github.com/atilaneves/unencumbered

I especially like registering functions that take the parameters 
with the types they need from the regexp captures, as well as the 
compile-time failures that come from that if done incorrectly.

Now I just need to use in "real life".

Atila
Apr 23 2014
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 23/04/14 15:24, Atila Neves wrote:

 Like testing with Cucumber? Wish you could call native D code with it?
 Now you can!

 http://code.dlang.org/packages/unencumbered
 https://github.com/atilaneves/unencumbered

 I especially like registering functions that take the parameters with
 the types they need from the regexp captures, as well as the
 compile-time failures that come from that if done incorrectly.

 Now I just need to use in "real life".


This is awesome. I've been thinking several times about implementing 
something like this. Now I don't have to :)

How do I set up the environment to use this? How complicated is it with 
the server and wire protocol?

-- 
/Jacob Carlborg
Apr 23 2014
parent reply "Atila Neves" <atila.neves gmail.com> writes:
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.

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?
           begin
              socket = TCPSocket.new('localhost', port)
           rescue Errno::ECONNREFUSED
             #keep trying until the server is up or we time out
           end
         end
       end
     end

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

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

Atila

On Wednesday, 23 April 2014 at 14:58:26 UTC, Jacob Carlborg wrote:

 On 23/04/14 15:24, Atila Neves wrote:

 Like testing with Cucumber? Wish you could call native D code 
 with it?
 Now you can!

 http://code.dlang.org/packages/unencumbered
 https://github.com/atilaneves/unencumbered

 I especially like registering functions that take the 
 parameters with
 the types they need from the regexp captures, as well as the
 compile-time failures that come from that if done incorrectly.

 Now I just need to use in "real life".


 This is awesome. I've been thinking several times about 
 implementing something like this. Now I don't have to :)

 How do I set up the environment to use this? How complicated is 
 it with the server and wire protocol?
Apr 23 2014
parent reply Jacob Carlborg <doob me.com> writes:
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?
            begin
               socket = TCPSocket.new('localhost', port)
            rescue Errno::ECONNREFUSED
              #keep trying until the server is up or we time out
            end
          end
        end
      end

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

 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
Apr 23 2014
next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
 Aha, their they are. I didn't noticed the step definitions 
 before. Especially confusing since you do have a 
 step_definitions directory.


I think I had to create that directory to put the .wire file in 
there. I can't remember.


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


I did, yeah, that's why I asked that question recently about 
calling D from Ruby. I also thought of using Thrift and played 
about with it but in the end decided that the simplest option is 
to just use the wire protocol. It even reports back D exception 
information back, so the only real thing I can see that's missing 
is the snippet suggestions when the steps aren't defined yet.

Atila
Apr 24 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 24/04/14 09:19, Atila Neves wrote:


 I did, yeah, that's why I asked that question recently about calling D
 from Ruby.


Right, that was you.


 I also thought of using Thrift and played about with it but
 in the end decided that the simplest option is to just use the wire
 protocol. It even reports back D exception information back, so the only
 real thing I can see that's missing is the snippet suggestions when the
 steps aren't defined yet.


If Ruby is embedded Cucumber could be embedded as well, perhaps. Then 
you could get an executable without dependencies.

-- 
/Jacob Carlborg
Apr 24 2014
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 24 April 2014 at 14:10:07 UTC, Jacob Carlborg wrote:

 On 24/04/14 09:19, Atila Neves wrote:


 I did, yeah, that's why I asked that question recently about 
 calling D
 from Ruby.


 Right, that was you.


 I also thought of using Thrift and played about with it but
 in the end decided that the simplest option is to just use the 
 wire
 protocol. It even reports back D exception information back, 
 so the only
 real thing I can see that's missing is the snippet suggestions 
 when the
 steps aren't defined yet.


 If Ruby is embedded Cucumber could be embedded as well, 
 perhaps. Then you could get an executable without dependencies.


Or I could carry on implementing all the Cucumber features and 
end up with an executable that does everything the Ruby version 
does. I'm happy with what I've got now though, but the embedding 
thing is interesting. I just decided that embedding was too much 
work.

Atila
Apr 25 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-04-25 10:31, Atila Neves wrote:


 Or I could carry on implementing all the Cucumber features and end up
 with an executable that does everything the Ruby version does. I'm happy
 with what I've got now though, but the embedding thing is interesting. I
 just decided that embedding was too much work.


I see.

A pure D implementation would be even better.

-- 
/Jacob Carlborg
Apr 26 2014
parent "Atila Neves" <atila.neves gmail.com> writes:
On Saturday, 26 April 2014 at 09:36:30 UTC, Jacob Carlborg wrote:

 On 2014-04-25 10:31, Atila Neves wrote:


 Or I could carry on implementing all the Cucumber features and 
 end up
 with an executable that does everything the Ruby version does. 
 I'm happy
 with what I've got now though, but the embedding thing is 
 interesting. I
 just decided that embedding was too much work.


 I see.

 A pure D implementation would be even better.


I thought of that, but decided it wasn't worth the bother. The 
Ruby version already exists, is familiar to pretty much anyone 
who's used or heard of Cucumber, and works.
To me a pure D implementation would be cool in and of itself, but 
personally wouldn't be that much better or useful as using the 
wire protocol.

Atila
Apr 28 2014
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
 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




You have a MQTT broker? Free? Open-source? Can I haz teh code plx!
Apr 25 2014
next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 25.04.2014 15:00, schrieb Dejan Lekic:

 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




 You have a MQTT broker? Free? Open-source? Can I haz teh code plx!


https://github.com/atilaneves/mqtt

BTW, shouldn't it be registered on code.dlang.org?
Apr 25 2014
parent "Atila Neves" <atila.neves gmail.com> writes:
On Friday, 25 April 2014 at 13:07:43 UTC, Sönke Ludwig wrote:

 Am 25.04.2014 15:00, schrieb Dejan Lekic:

 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




 You have a MQTT broker? Free? Open-source? Can I haz teh code 
 plx!


 https://github.com/atilaneves/mqtt

 BTW, shouldn't it be registered on code.dlang.org?


I guess! Doing it now.

Atila
Apr 25 2014
prev sibling parent "Atila Neves" <atila.neves gmail.com> writes:
On Friday, 25 April 2014 at 13:00:20 UTC, Dejan Lekic wrote:

 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




 You have a MQTT broker? Free? Open-source? Can I haz teh code 
 plx!


https://github.com/atilaneves/mqtt

Only does QOS 0, doesn't do authentication, but it works. I wrote 
two blog posts about it and performance on 
http://atilanevesoncode.wordpress.com/.

Atila
Apr 25 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-04-23 15:24, Atila Neves wrote:

 Like testing with Cucumber? Wish you could call native D code with it?
 Now you can!

 http://code.dlang.org/packages/unencumbered
 https://github.com/atilaneves/unencumbered

 I especially like registering functions that take the parameters with
 the types they need from the regexp captures, as well as the
 compile-time failures that come from that if done incorrectly.

 Now I just need to use in "real life".


BTW, why is the description passed as a template argument to the 
Cucumber keywords.  Given!("foo") instead of  Given("foo")?

-- 
/Jacob Carlborg
Apr 24 2014
next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 24 April 2014 at 18:53:22 UTC, Jacob Carlborg wrote:

 On 2014-04-23 15:24, Atila Neves wrote:

 Like testing with Cucumber? Wish you could call native D code 
 with it?
 Now you can!

 http://code.dlang.org/packages/unencumbered
 https://github.com/atilaneves/unencumbered

 I especially like registering functions that take the 
 parameters with
 the types they need from the regexp captures, as well as the
 compile-time failures that come from that if done incorrectly.

 Now I just need to use in "real life".


 BTW, why is the description passed as a template argument to 
 the Cucumber keywords.  Given!("foo") instead of  Given("foo")?


Ehm... because until now I didn't know that  Given("foo") was 
possible. In my head I was doing compile-time stuff so everything 
had to be compile-time, if that makes any sense.

After I read the above I wasn't even sure how  Given("foo") would 
work so I wrote some code and now know that all I need is a 
struct with a regular string field. I think the documenation on 
http://dlang.org/attribute.html is severely lacking.

I think I have some refactoring to do now. Thanks for pointing 
this out!


Atila
Apr 25 2014
next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Friday, 25 April 2014 at 08:45:20 UTC, Atila Neves wrote:

 On Thursday, 24 April 2014 at 18:53:22 UTC, Jacob Carlborg 
 wrote:

 On 2014-04-23 15:24, Atila Neves wrote:

 Like testing with Cucumber? Wish you could call native D code 
 with it?
 Now you can!

 http://code.dlang.org/packages/unencumbered
 https://github.com/atilaneves/unencumbered

 I especially like registering functions that take the 
 parameters with
 the types they need from the regexp captures, as well as the
 compile-time failures that come from that if done incorrectly.

 Now I just need to use in "real life".


 BTW, why is the description passed as a template argument to 
 the Cucumber keywords.  Given!("foo") instead of  Given("foo")?


 Ehm... because until now I didn't know that  Given("foo") was 
 possible. In my head I was doing compile-time stuff so 
 everything had to be compile-time, if that makes any sense.

 After I read the above I wasn't even sure how  Given("foo") 
 would work so I wrote some code and now know that all I need is 
 a struct with a regular string field. I think the documenation 
 on http://dlang.org/attribute.html is severely lacking.

 I think I have some refactoring to do now. Thanks for pointing 
 this out!


 Atila


Hmm. So for the string argument is fine, unfortunately I also 
need to know the line number of the step definition, and that 
doesn't work:

struct Given {
     this(string s, ulong l = __LINE__) {
         this.s = s;
         this.l = l;
     }
     string s;
     ulong l;
}


 Given("foobar")
auto func() pure nothrow  safe {

}

void main() {
     foreach(attr; __traits(getAttributes, func)) {
         pragma(msg, "s is ", __traits(getMember, attr, "l"));
     }
}


I get:

s is attr_str.d(21): Error: variable attr cannot be read at 
compile time
attr_str.d(21):        while evaluating pragma(msg, 
__traits(getMember, attr, "l"))
Apr 25 2014
parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Friday, 25 April 2014 at 08:52:18 UTC, Atila Neves wrote:

 On Friday, 25 April 2014 at 08:45:20 UTC, Atila Neves wrote:

 On Thursday, 24 April 2014 at 18:53:22 UTC, Jacob Carlborg 
 wrote:

 On 2014-04-23 15:24, Atila Neves wrote:

 Like testing with Cucumber? Wish you could call native D 
 code with it?
 Now you can!

 http://code.dlang.org/packages/unencumbered
 https://github.com/atilaneves/unencumbered

 I especially like registering functions that take the 
 parameters with
 the types they need from the regexp captures, as well as the
 compile-time failures that come from that if done 
 incorrectly.

 Now I just need to use in "real life".


 BTW, why is the description passed as a template argument to 
 the Cucumber keywords.  Given!("foo") instead of 
  Given("foo")?


 Ehm... because until now I didn't know that  Given("foo") was 
 possible. In my head I was doing compile-time stuff so 
 everything had to be compile-time, if that makes any sense.

 After I read the above I wasn't even sure how  Given("foo") 
 would work so I wrote some code and now know that all I need 
 is a struct with a regular string field. I think the 
 documenation on http://dlang.org/attribute.html is severely 
 lacking.

 I think I have some refactoring to do now. Thanks for pointing 
 this out!


 Atila


 Hmm. So for the string argument is fine, unfortunately I also 
 need to know the line number of the step definition, and that 
 doesn't work:

 struct Given {
     this(string s, ulong l = __LINE__) {
         this.s = s;
         this.l = l;
     }
     string s;
     ulong l;
 }


  Given("foobar")
 auto func() pure nothrow  safe {

 }

 void main() {
     foreach(attr; __traits(getAttributes, func)) {
         pragma(msg, "s is ", __traits(getMember, attr, "l"));
     }
 }


 I get:

 s is attr_str.d(21): Error: variable attr cannot be read at 
 compile time
 attr_str.d(21):        while evaluating pragma(msg, 
 __traits(getMember, attr, "l"))


struct Given {
     this(ulong l = __LINE__)(string s) {
         this.s = s;
		this.l = l;
     }
     string s;
     ulong l;
}


 Given("foobar")
auto func() pure nothrow  safe {

}

void main() {
	pragma(msg, "s is ", getGivenL!func);
}

pure ulong getGivenL(alias symbol)() {
	foreach(attr; __traits(getAttributes, func)) {
		static if (is(typeof(attr) == Given)) {
			return attr.l;	
		}
	}
	assert(0);
}

Basically move the "checking" of UDA's to specialist functions 
that are reusable.
Also when using things like __LINE__ keep them to template args, 
as they are inferred to the initiation if possible.
Apr 25 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 25 April 2014 at 09:45:06 UTC, Rikki Cattermole wrote:

 Also when using things like __LINE__ keep them to template 
 args, as they are inferred to the initiation if possible.


This is antipattern. Default function arguments for __LINE__ and 
__FILE__ are also evaluated at call site. Moving this to template 
parameter creates huge amount of template bloat and must be used 
only if there is no other way around (that usually implies 
variadic arguments)
Apr 25 2014
parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Friday, 25 April 2014 at 10:02:45 UTC, Dicebot wrote:

 On Friday, 25 April 2014 at 09:45:06 UTC, Rikki Cattermole 
 wrote:

 Also when using things like __LINE__ keep them to template 
 args, as they are inferred to the initiation if possible.


 This is antipattern. Default function arguments for __LINE__ 
 and __FILE__ are also evaluated at call site. Moving this to 
 template parameter creates huge amount of template bloat and 
 must be used only if there is no other way around (that usually 
 implies variadic arguments)


True in this specific case it might be over the top.
Apr 25 2014
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Friday, 25 April 2014 at 10:20:47 UTC, Rikki Cattermole wrote:

 On Friday, 25 April 2014 at 10:02:45 UTC, Dicebot wrote:

 On Friday, 25 April 2014 at 09:45:06 UTC, Rikki Cattermole 
 wrote:

 Also when using things like __LINE__ keep them to template 
 args, as they are inferred to the initiation if possible.


 This is antipattern. Default function arguments for __LINE__ 
 and __FILE__ are also evaluated at call site. Moving this to 
 template parameter creates huge amount of template bloat and 
 must be used only if there is no other way around (that 
 usually implies variadic arguments)


 True in this specific case it might be over the top.


It was a template parameter before anyway. Also, this is for 
acceptance/feature/integration testing, so I doubt anyone would 
care how much bloat it generates as long as it gets the job done.

Is there any other way to achieve  Given("regexp") that also gets 
passed in the line number automatically without the template 
param? If so I'll glady use it, if not I think Rikki's solution 
seems to be the simplest so far.

Atila
Apr 25 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 25 April 2014 at 11:11:18 UTC, Atila Neves wrote:

 Is there any other way to achieve  Given("regexp") that also 
 gets passed in the line number automatically without the 
 template param? If so I'll glady use it, if not I think Rikki's 
 solution seems to be the simplest so far.

 Atila


Just change struct constructor back to
     this(string s, ulong l = __LINE__) {
in Riki's snippet
Apr 25 2014
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 25 April 2014 at 11:11:18 UTC, Atila Neves wrote:

 On Friday, 25 April 2014 at 10:20:47 UTC, Rikki Cattermole 
 wrote:

 On Friday, 25 April 2014 at 10:02:45 UTC, Dicebot wrote:

 On Friday, 25 April 2014 at 09:45:06 UTC, Rikki Cattermole 
 wrote:

 Also when using things like __LINE__ keep them to template 
 args, as they are inferred to the initiation if possible.


 This is antipattern. Default function arguments for __LINE__ 
 and __FILE__ are also evaluated at call site. Moving this to 
 template parameter creates huge amount of template bloat and 
 must be used only if there is no other way around (that 
 usually implies variadic arguments)


 True in this specific case it might be over the top.


 It was a template parameter before anyway. Also, this is for 
 acceptance/feature/integration testing, so I doubt anyone would 
 care how much bloat it generates as long as it gets the job 
 done.


It will hurt build-times, so it's worth avoiding.
Apr 25 2014
parent "Atila Neves" <atila.neves gmail.com> writes:
On Friday, 25 April 2014 at 12:18:41 UTC, John Colvin wrote:

 On Friday, 25 April 2014 at 11:11:18 UTC, Atila Neves wrote:

 On Friday, 25 April 2014 at 10:20:47 UTC, Rikki Cattermole 
 wrote:

 On Friday, 25 April 2014 at 10:02:45 UTC, Dicebot wrote:

 On Friday, 25 April 2014 at 09:45:06 UTC, Rikki Cattermole 
 wrote:

 Also when using things like __LINE__ keep them to template 
 args, as they are inferred to the initiation if possible.


 This is antipattern. Default function arguments for __LINE__ 
 and __FILE__ are also evaluated at call site. Moving this to 
 template parameter creates huge amount of template bloat and 
 must be used only if there is no other way around (that 
 usually implies variadic arguments)


 True in this specific case it might be over the top.


 It was a template parameter before anyway. Also, this is for 
 acceptance/feature/integration testing, so I doubt anyone 
 would care how much bloat it generates as long as it gets the 
 job done.


 It will hurt build-times, so it's worth avoiding.


Normally I'd agree. But it'll take longer to run the server and 
the tests themselves than it'll take to build anyway, so it 
really doesn't matter that much.

Now, if it were for _unit_ tests... hmm, speaking of which I 
should probably try and optimise that for unit-threaded. But that 
means profiling the compiler I guess.

Atila
Apr 25 2014
prev sibling next sibling parent reply "Jacob Carlborg" <doob me.com> writes:
On Friday, 25 April 2014 at 08:45:20 UTC, Atila Neves wrote:


 After I read the above I wasn't even sure how  Given("foo") 
 would work so I wrote some code and now know that all I need is 
 a struct with a regular string field. I think the documenation 
 on http://dlang.org/attribute.html is severely lacking.


What do you mean, it's right there, at the bottom of the first 
example [1]:

 Bar(3) int d;

[1] http://dlang.org/attribute.html#UserDefinedAttribute

--
/Jacob Carlborg
Apr 26 2014
parent "Atila Neves" <atila.neves gmail.com> writes:
On Saturday, 26 April 2014 at 07:51:45 UTC, Jacob Carlborg wrote:

 On Friday, 25 April 2014 at 08:45:20 UTC, Atila Neves wrote:


 After I read the above I wasn't even sure how  Given("foo") 
 would work so I wrote some code and now know that all I need 
 is a struct with a regular string field. I think the 
 documenation on http://dlang.org/attribute.html is severely 
 lacking.


 What do you mean, it's right there, at the bottom of the first 
 example [1]:

  Bar(3) int d;

 [1] http://dlang.org/attribute.html#UserDefinedAttribute

 --
 /Jacob Carlborg


Oh. Oops.

Atila
Apr 28 2014
prev sibling parent "Jacob Carlborg" <doob me.com> writes:
On Friday, 25 April 2014 at 08:45:20 UTC, Atila Neves wrote:


 Ehm... because until now I didn't know that  Given("foo") was 
 possible. In my head I was doing compile-time stuff so 
 everything had to be compile-time, if that makes any sense.

 After I read the above I wasn't even sure how  Given("foo") 
 would work so I wrote some code and now know that all I need is 
 a struct with a regular string field. I think the documenation 
 on http://dlang.org/attribute.html is severely lacking.


BTW, I think it's possible to use a plain function as well, which 
returns a struct. In this case, "Given" would be the function.

--
/Jacob Carlborg
Apr 26 2014
prev sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 24 April 2014 at 18:53:22 UTC, Jacob Carlborg wrote:

 On 2014-04-23 15:24, Atila Neves wrote:

 Like testing with Cucumber? Wish you could call native D code 
 with it?
 Now you can!

 http://code.dlang.org/packages/unencumbered
 https://github.com/atilaneves/unencumbered

 I especially like registering functions that take the 
 parameters with
 the types they need from the regexp captures, as well as the
 compile-time failures that come from that if done incorrectly.

 Now I just need to use in "real life".


 BTW, why is the description passed as a template argument to 
 the Cucumber keywords.  Given!("foo") instead of  Given("foo")?


Finally got around to it and now it's  Given("foo") like it 
should've been. Bumped the version up to v0.2.0.

Atila
May 02 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-05-02 17:21, Atila Neves wrote:


 Finally got around to it and now it's  Given("foo") like it should've
 been. Bumped the version up to v0.2.0.


Cool :)

-- 
/Jacob Carlborg
May 04 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-04-23 15:24, Atila Neves wrote:

 Like testing with Cucumber? Wish you could call native D code with it?
 Now you can!

 http://code.dlang.org/packages/unencumbered
 https://github.com/atilaneves/unencumbered

 I especially like registering functions that take the parameters with
 the types they need from the regexp captures, as well as the
 compile-time failures that come from that if done incorrectly.

 Now I just need to use in "real life".


It would be very nice to have something like Aruba in D together with 
this. If you haven't heard of it it's basically a library making it 
easier to test CLI applications, often used together with Cucumber. I 
think it's used by Cucumber itself.

-- 
/Jacob Carlborg
Apr 24 2014
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 24 April 2014 at 18:55:20 UTC, Jacob Carlborg wrote:

 On 2014-04-23 15:24, Atila Neves wrote:

 Like testing with Cucumber? Wish you could call native D code 
 with it?
 Now you can!

 http://code.dlang.org/packages/unencumbered
 https://github.com/atilaneves/unencumbered

 I especially like registering functions that take the 
 parameters with
 the types they need from the regexp captures, as well as the
 compile-time failures that come from that if done incorrectly.

 Now I just need to use in "real life".


 It would be very nice to have something like Aruba in D 
 together with this. If you haven't heard of it it's basically a 
 library making it easier to test CLI applications, often used 
 together with Cucumber. I think it's used by Cucumber itself.


Yeah, I know Aruba. Well, for all of about two weeks :) Why would 
you want Aruba in D, though? You can just use the Ruby version.

Atila
Apr 25 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-04-25 10:32, Atila Neves wrote:


 Yeah, I know Aruba. Well, for all of about two weeks :) Why would you
 want Aruba in D, though? You can just use the Ruby version.


Sure I can, I already does this. I would be quite nice with mostly pure 
D tools. People have been almost hostile in my attempts to use D 
together with Ruby. I was building a package manager that use Ruby for 
writing the package description files. That was far from popular.

Oh, then why are you adding support for D to Cucumber ;)

-- 
/Jacob Carlborg
Apr 26 2014
parent "Atila Neves" <atila.neves gmail.com> writes:
On Saturday, 26 April 2014 at 09:40:14 UTC, Jacob Carlborg wrote:

 On 2014-04-25 10:32, Atila Neves wrote:


 Yeah, I know Aruba. Well, for all of about two weeks :) Why 
 would you
 want Aruba in D, though? You can just use the Ruby version.


 Sure I can, I already does this. I would be quite nice with 
 mostly pure D tools. People have been almost hostile in my 
 attempts to use D together with Ruby. I was building a package 
 manager that use Ruby for writing the package description 
 files. That was far from popular.

 Oh, then why are you adding support for D to Cucumber ;)


Ah, well, so I can easily have Cucumber steps to call D code that 
has side-effects. Anything else I unit test.

I can even test some of my D code without this project. In the 
MQTT case I just implemented the step definitions in Ruby, opened 
a socket and sent in binary data. But it'd be handy to call D 
code as well, hence the project.

Actually I started writing this so I could learn BDD with 
Cucumber on a D project. Little did I know that Cucumber uses 
itself to specify behaviour, which meant I learned BDD with 
Cucumber as I was doing a project to learn BDD with Cucumber! So 
meta.

Atila
Apr 28 2014