On Wednesday, 3 June 2015 at 07:30:31 UTC, Jacob Carlborg wrote:
> On 2015-04-20 15:28, Atila Neves wrote:
>> Original library: http://code.dlang.org/packages/unit-threaded
>> PR: https://github.com/D-Programming-Language/phobos/pull/3207
>
> * Would it be possible to make the "should" functions more composeable. Instead of "a.shouldEqual(b)" something like "a.should.equal(b)". Then you don't need a separate "shouldNot" function for all functions, just one

Easily. I toyed with this syntax

foo().should == 3;

And that works. Unfortunately it doesn't work for `!=` or `>=`. I could do the other operators as compile-time strings, but then `==` would be the weird one out. In the end I didn't think there was much value of typing `should.equal` over `shouldEqual` and left it as it is.

There's already some controversy over syntax as it is, see Dicebot's comments.

> * Is it possible to create custom "should functions" or marchers as RSpec would call them? Otherwise perhaps the above suggestion would make that easier

I'd have to think about that. First we'd have to agree on how things should look, though.

> * I would recommend writing the actual operator used for a given "should function" in the documentation

Good idea.

> * Is there a function to compare if two objects are the actual same objects in memory, i.e. comparing using "is"?

No, but it'd be easy to write. Is that actually needed though?  It doesn't seem something that would come up often, and one could always write `&foo.shouldEqual(&bar)`.

> * Latest versions of RSpec does not allow to specify an exception type when a test should not throw an exception. I don't recall the exact reason now but it might be worth investigating and taking in to consideration

I might take a look, but really all I've ever seen is expecting to throw a particular exception anyway.

> * Is there any special output when running the tests? In that case, how does it look like? Is it possible to use different formatters for the output and create custom ones?

Yes. It looks identical to the library that preceded this, unit-threaded. There are examples in the repository for both passing and failing tests on purpose to show what the output is like.

Atila

On Wednesday, 3 June 2015 at 07:42:58 UTC, Jacob Carlborg wrote:
> On 2015-04-20 15:28, Atila Neves wrote:
>> Original library: http://code.dlang.org/packages/unit-threaded
>> PR: https://github.com/D-Programming-Language/phobos/pull/3207
>
> No Cucumber tests? This is what you're up against [1] ;). I think the Cucumber tests in RSpec are a perfect example of how to use Cucumber correctly. And this Relish site is able to generate good looking documentation based on Cucumber feature files.
>
> [1] http://www.relishapp.com/rspec/rspec-core/docs

This work was done before I learned Cucumber. In fact, one of the motivations for learning it in the first place were the bugs I kept introducing and not knowing about. This is (hopefully) going into Phobos, so even if I had Cucumber tests for unit-threaded I probably wouldn't include them in the pull request. It's a big and important one already without having to discuss whether or not we want to test the standard library with an external tool.

Atila

On 2015-06-03 12:50, Atila Neves wrote:

> Easily. I toyed with this syntax
>
> foo().should == 3;
>
> And that works. Unfortunately it doesn't work for `!=` or `>=`. I could
> do the other operators as compile-time strings, but then `==` would be
> the weird one out. In the end I didn't think there was much value of
> typing `should.equal` over `shouldEqual` and left it as it is.

The reason would/might be custom "should functions"/matchers.

> I'd have to think about that. First we'd have to agree on how things
> should look, though.

Yeah, but I would think that if the "should" function was separate from the operator used it would be easier, but I don't know.


> No, but it'd be easy to write. Is that actually needed though? It
> doesn't seem something that would come up often, and one could always
> write `&foo.shouldEqual(&bar)`.

I don't know. RSpec has it.

> I might take a look, but really all I've ever seen is expecting to throw
> a particular exception anyway.

This was for when you're expecting a function to _not_ throw an exception.

-- 
/Jacob Carlborg

On 2015-06-03 12:52, Atila Neves wrote:

> This work was done before I learned Cucumber. In fact, one of the
> motivations for learning it in the first place were the bugs I kept
> introducing and not knowing about. This is (hopefully) going into
> Phobos, so even if I had Cucumber tests for unit-threaded I probably
> wouldn't include them in the pull request. It's a big and important one
> already without having to discuss whether or not we want to test the
> standard library with an external tool.

Yeah, I would not recommend adding Cucumber tests in a pull request.

-- 
/Jacob Carlborg

On Thursday, 4 June 2015 at 06:33:27 UTC, Jacob Carlborg wrote:
> On 2015-06-03 12:50, Atila Neves wrote:
>
>> Easily. I toyed with this syntax
>>
>> foo().should == 3;
>>
>> And that works. Unfortunately it doesn't work for `!=` or `>=`. I could
>> do the other operators as compile-time strings, but then `==` would be
>> the weird one out. In the end I didn't think there was much value of
>> typing `should.equal` over `shouldEqual` and left it as it is.
>
> The reason would/might be custom "should functions"/matchers.

"would/might"? YAGNI.

>> No, but it'd be easy to write. Is that actually needed though? It
>> doesn't seem something that would come up often, and one could always
>> write `&foo.shouldEqual(&bar)`.
>
> I don't know. RSpec has it.

Ruby doesn't have `&`. It's not needed in D.

>> I might take a look, but really all I've ever seen is expecting to throw
>> a particular exception anyway.
>
> This was for when you're expecting a function to _not_ throw an exception.

I used to think this was useful, probably due to symmetry. In practice, it's not. If you want to assert an expression doesn't throw, just... write the expression. The test will fail anyway if it throws.


Atila

On Monday, 1 June 2015 at 16:38:06 UTC, Atila Neves wrote:
> I think I've addressed all comments now, except for Robert's one on whether or not multi-threading should be on by default. Also, after much toiling I've managed to get the docs up here:
>
> http://atilaneves.github.io/phobos/phobos/std_experimental_testing.html
>
> It really should be a lot easier to generate the docs. Anyway, please give it a look and destroy away.
>
> Atila
>
> On Monday, 20 April 2015 at 13:28:30 UTC, Atila Neves wrote:
>> [...]

Methinks all comments have been addressed again, except for the multi-threading by default or not.

Atila

On Friday, 19 June 2015 at 15:24:25 UTC, Atila Neves wrote:
> On Monday, 1 June 2015 at 16:38:06 UTC, Atila Neves wrote:
>> I think I've addressed all comments now, except for Robert's one on whether or not multi-threading should be on by default. Also, after much toiling I've managed to get the docs up here:
>>
>> http://atilaneves.github.io/phobos/phobos/std_experimental_testing.html
>>
>> It really should be a lot easier to generate the docs. Anyway, please give it a look and destroy away.
>>
>> Atila
>>
>> On Monday, 20 April 2015 at 13:28:30 UTC, Atila Neves wrote:
>>> [...]
>
> Methinks all comments have been addressed again, except for the multi-threading by default or not.
>
> Atila

Bump.

Personally I think this is ready for voting.

Atila

On Monday, 22 June 2015 at 14:27:24 UTC, Atila Neves wrote:
> On Friday, 19 June 2015 at 15:24:25 UTC, Atila Neves wrote:
>> On Monday, 1 June 2015 at 16:38:06 UTC, Atila Neves wrote:
>>> I think I've addressed all comments now, except for Robert's one on whether or not multi-threading should be on by default. Also, after much toiling I've managed to get the docs up here:
>>>
>>> http://atilaneves.github.io/phobos/phobos/std_experimental_testing.html
>>>
>>> It really should be a lot easier to generate the docs. Anyway, please give it a look and destroy away.
>>>
>>> Atila
>>>
>>> On Monday, 20 April 2015 at 13:28:30 UTC, Atila Neves wrote:
>>>> [...]
>>
>> Methinks all comments have been addressed again, except for the multi-threading by default or not.
>>
>> Atila
>
> Bump.
>
> Personally I think this is ready for voting.
>
> Atila

Can I please get either 1) comments 2) a LGTM? Ideally this should make 2.068, assuming it's good enough.

Atila

Nothing jumps out at me as being especially bad. The posix escape codes could also be Windows compatible by rewriting them somehow, instead of building a string, make a struct message { int color; string text; } or something that you pass to the thread... but since that's an internal implementation detail that isn't necessary to work, meh.

The docs in package.d could show more higher level examples too, before I looked at the code, I didn't realize there was more to it.

Just in case it wasn't clear : I will vote "no" on this proposal as long as it features longish "readable" names like "shouldEquals".