On 4/2/15 3:32 AM, Jacob Carlborg wrote:
> On 2015-04-01 21:28, Ary Borenszweig wrote:
>
>> No, it's actually much simpler but less powerful. This is because the
>> language is not as dynamic as Ruby. But we'd like to keep things as
>> simple as possible.
>
> Can't you implement that using macros?

We can. But then it becomes harder to understand what's going on. In RSpec I don't quite understand what's going on really, and I like a bit of magic but not too much of it.

In fact with macros it's not that simple because you need to remember
the context where you are defining stuff, so that might need adding that
capabilities to macros, which will complicate the language.

>
>> But right now you get these things:
>
> This sounds all great. But lowering groups and examples to classes and
> methods takes it to the next level.

Somebody also started writing a minitest clone: https://github.com/ysbaddaden/minitest.cr . Implementing a DSL on top of that using regular code or macros should be possible. But right now the features we have are enough.

On Wednesday, 1 April 2015 at 20:48:43 UTC, Atila Neves wrote:
> On Wednesday, 1 April 2015 at 19:31:37 UTC, Dicebot wrote:
>> P.S. I hate all the Ruby testing facilities, hate with bloody passion.
>
> You're going to _love_ my DConf talk ;) I was expecting that already, you let me know what you thought of them last year!
>
> Atila

Oh yeah, looking forward to listening it :) I had an unpleasant experience of encountering Cucumber when trying to contribute to dstep so this specific name is like a trigger to me :)

On 4/2/15 1:34 PM, Dicebot wrote:
> On Wednesday, 1 April 2015 at 20:48:43 UTC, Atila Neves wrote:
>> On Wednesday, 1 April 2015 at 19:31:37 UTC, Dicebot wrote:
>>> P.S. I hate all the Ruby testing facilities, hate with bloody passion.
>>
>> You're going to _love_ my DConf talk ;) I was expecting that already,
>> you let me know what you thought of them last year!
>>
>> Atila
>
> Oh yeah, looking forward to listening it :) I had an unpleasant
> experience of encountering Cucumber when trying to contribute to dstep
> so this specific name is like a trigger to me :)

Having never used Cucumber but having been interested in it, what was the unpleasantness?

On Thursday, 2 April 2015 at 20:55:04 UTC, David Gileadi wrote:
> On 4/2/15 1:34 PM, Dicebot wrote:
>> On Wednesday, 1 April 2015 at 20:48:43 UTC, Atila Neves wrote:
>>> On Wednesday, 1 April 2015 at 19:31:37 UTC, Dicebot wrote:
>>>> P.S. I hate all the Ruby testing facilities, hate with bloody passion.
>>>
>>> You're going to _love_ my DConf talk ;) I was expecting that already,
>>> you let me know what you thought of them last year!
>>>
>>> Atila
>>
>> Oh yeah, looking forward to listening it :) I had an unpleasant
>> experience of encountering Cucumber when trying to contribute to dstep
>> so this specific name is like a trigger to me :)
>
> Having never used Cucumber but having been interested in it, what was the unpleasantness?

The very fact of being forced to install some external application) which is not even available in my distro repositories) to run set of basic tests that could be done with 10 line D or shell script instead.

It is hardly surprising that so far I preferred to submit pull requests without testing instead.

On Thu, Apr 2, 2015 at 12:04 PM, Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> ...
>>
>
> The way I see it, the notion of having one build with strippable unittests is a nice idea but technically challenging. It's also low impact - today concurrent CPU is cheap so running two concurrent unrelated builds can be made as fast as one.
>
>
This works for me.  The important part is that the resultant artifacts of the build have had their exact code tested, doesn't really matter if it's the exact same bits or just logical equivalent.  As long as it is the _exact_ same, which means test-only dependencies are not part of the being-tested code.


> The simple effective step toward improvement is to uniformize the format
> of assertion errors in unittests and to make it easy with tooling to create
> unittest and non-unittest builds that are gated by the unittests succeeding.
>
>
Nomenclature nitpick: one 'build' with concurrent compile/test steps. Artifacts of build should include a tested library/executable and (uniformly formatted of course) test report.

On Thursday, 2 April 2015 at 20:55:04 UTC, David Gileadi wrote:
>
> Having never used Cucumber but having been interested in it, what was the unpleasantness?

Dealing with it at work, I find it puts us scarily at the mercy of regexen in Ruby, which is unsettling to say the least.  More pressingly, the "plain English" method of writing tests hinders my ability to figure out what the test is actually trying to do.  There's not enough structure to give you good visual anchors that are easy to follow, so I end up having to build a mental model of an entire feature file every time I look at it.  It's hugely inconvenient.  And if I can't remember what a phrase corresponds to, I have to hunt down the implementation and read that anyway, so it's not saving any time or making life any easier.

-Wyatt

On 4/2/15 2:46 PM, Wyatt wrote:
> On Thursday, 2 April 2015 at 20:55:04 UTC, David Gileadi wrote:
>>
>> Having never used Cucumber but having been interested in it, what was
>> the unpleasantness?
>
> Dealing with it at work, I find it puts us scarily at the mercy of
> regexen in Ruby, which is unsettling to say the least.  More pressingly,
> the "plain English" method of writing tests hinders my ability to figure
> out what the test is actually trying to do. There's not enough structure
> to give you good visual anchors that are easy to follow, so I end up
> having to build a mental model of an entire feature file every time I
> look at it.  It's hugely inconvenient.  And if I can't remember what a
> phrase corresponds to, I have to hunt down the implementation and read
> that anyway, so it's not saving any time or making life any easier.
>
> -Wyatt

On 4/2/15 2:32 PM, Dicebot wrote:
> The very fact of being forced to install some external application)
> which is not even available in my distro repositories) to run set of
> basic tests that could be done with 10 line D or shell script instead.
>
> It is hardly surprising that so far I preferred to submit pull requests
> without testing instead.

Thanks to you both for the answers!

On 2015-04-02 21:11, Ary Borenszweig wrote:

> We can. But then it becomes harder to understand what's going on. In
> RSpec I don't quite understand what's going on really, and I like a bit
> of magic but not too much of it.

It's quite straightforward to implement, in Ruby as least. Something like this:

module DSL
  def describe(name, &block)
    context = Class.new(self)
    context.send(:extend, DSL)
    context.instance_eval(&block)
  end

  def it(name, &block)
    send(:define_method, name, &block)
  end
end

class Foo
  extend DSL

  describe 'foo' do
    it 'bar' do
      p 'asd'
    end
  end
end

You need to register the tests somehow also but be able to run them, but this is the basic idea. I cheated here and used a class to start with to simplify the example.

> In fact with macros it's not that simple because you need to remember
> the context where you are defining stuff, so that might need adding that
> capabilities to macros, which will complicate the language.

Yeah, I don't really now how macros work in Cyrstal.

-- 
/Jacob Carlborg

On 2015-04-02 22:34, Dicebot wrote:

> Oh yeah, looking forward to listening it :) I had an unpleasant
> experience of encountering Cucumber when trying to contribute to dstep
> so this specific name is like a trigger to me :)

Yeah, I don't like how it ended up in DStep. I'm using it completely wrong, I'm just too lazy to fix it. Currently it basically compares two strings, the input and the output. I had some big plans for it but that never happened. Currently The only advantage is the runner, i.e. it shows a nice output, it's possible to only run a single test, it does stop all test at the first failure. All the thing Andrei wants to fix in D it seems :)

In the case of DStep you can mostly ignore the Cucumber part and just focus on the input and expected files. You can even run the tests without it, just run DStep on the input file compare the output with the expected file.

-- 
/Jacob Carlborg

On 2015-04-02 23:46, Wyatt wrote:

> Dealing with it at work, I find it puts us scarily at the mercy of
> regexen in Ruby, which is unsettling to say the least.  More pressingly,
> the "plain English" method of writing tests hinders my ability to figure
> out what the test is actually trying to do. There's not enough structure
> to give you good visual anchors that are easy to follow, so I end up
> having to build a mental model of an entire feature file every time I
> look at it.  It's hugely inconvenient.  And if I can't remember what a
> phrase corresponds to, I have to hunt down the implementation and read
> that anyway, so it's not saving any time or making life any easier.

At work we're using Turnip [1], which basically is Gherkin (Cucumber) files running on top of RSpec, best of both worlds Dicebot ;). It has two big advatnages compared to regular Cucumber:

* It doesn't use regular expression for the steps, just plain strings

* The steps are implemented in modules which are later included where needed. They're not floating around in global space like in Cucumber

We also made some modifications so we have one file with one module matching one scenario, which is automatically included based on the scenario name. This made it possible to have steps that don't interfere with each other. We can have two steps which are identical in two different scenarios with two different implementations that doesn't conflict.

This also made it possible to take full advantage of RSpec, by creating instance variables that keeps the data across steps.

We're also currently experimenting with a gem (I can't recall its name right now) which allows to write the Cucumber steps inline in the RSpec tests, looking like this:

describe "foobar" do
  Steps "this is a scenario" do
    Given "some kind of setup" do
    end

    When "when something cool happens" do
    end

    Then "something even cooler will happen" do
    end
  end
end

[1] https://github.com/jnicklas/turnip

-- 
/Jacob Carlborg