www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.experimental.testing PR review

reply "Atila Neves" <atila.neves gmail.com> writes:
Original library: http://code.dlang.org/packages/unit-threaded
PR: https://github.com/D-Programming-Language/phobos/pull/3207

It's my first Phobos PR, I tried reading the wiki and doing 
what's required but bear with me if I've screwed up somehow.

I wasn't sure whether or not to split the PR. In the end I just 
took the existing library, edited it a lot and got it ready for 
review.

Unit test blocks can be named with  Name. They execute in 
parallel by default but that's only if the default runner is used.

Atila
Apr 20 2015
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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

 It's my first Phobos PR, I tried reading the wiki and doing what's
 required but bear with me if I've screwed up somehow.


Any new module must go through the review queue [1]. Ask here in the 
newsgroup for a review on the code. Generated documetnation and code 
should be available for the module. A review manager will volunteer to 
manage the review. When a module has been approved, first then should a 
pull request be created.

[1] http://wiki.dlang.org/Review_Queue

-- 
/Jacob Carlborg
Apr 20 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Monday, 20 April 2015 at 13:50:59 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

 It's my first Phobos PR, I tried reading the wiki and doing 
 what's
 required but bear with me if I've screwed up somehow.


 Any new module must go through the review queue [1]. Ask here 
 in the newsgroup for a review on the code. Generated 
 documetnation and code should be available for the module. A 
 review manager will volunteer to manage the review. When a 
 module has been approved, first then should a pull request be 
 created.

 [1] http://wiki.dlang.org/Review_Queue


I saw links to PRs past with generated docs but have/had no
idea how to get a similar result. Besides the html make target,
what is it a person has to do exactly? I'm going to edit the wiki
with this information as well.

Atila
Apr 20 2015
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-04-20 16:29, Atila Neves wrote:


 I saw links to PRs past with generated docs but have/had no
 idea how to get a similar result. Besides the html make target,
 what is it a person has to do exactly? I'm going to edit the wiki
 with this information as well.


Some developer use Ddox [1], some use the same way as Phobos uses. I 
think it's enough to add you're files to Phobos (including the 
makefiles) and the generate the documentation using "make" in the 
dlang.org repository.

[1] https://github.com/rejectedsoftware/ddox

-- 
/Jacob Carlborg
Apr 20 2015
prev sibling parent reply "Robert burner Schadek" <rburners gmail.com> writes:
On Monday, 20 April 2015 at 14:29:33 UTC, Atila Neves wrote:

 I saw links to PRs past with generated docs but have/had no
 idea how to get a similar result. Besides the html make target,
 what is it a person has to do exactly? I'm going to edit the 
 wiki


http://wiki.dlang.org/Building_DMD#Building_the_Docs
Apr 21 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Tuesday, 21 April 2015 at 08:17:37 UTC, Robert burner Schadek 
wrote:

 On Monday, 20 April 2015 at 14:29:33 UTC, Atila Neves wrote:

 I saw links to PRs past with generated docs but have/had no
 idea how to get a similar result. Besides the html make target,
 what is it a person has to do exactly? I'm going to edit the 
 wiki


 http://wiki.dlang.org/Building_DMD#Building_the_Docs


This part I'd figured out; it's the getting it online for others 
to see (and the need to do this as part of the PR) I had troubles 
with.

I did a lot of google searches for "site:dlang.org 
std.experimental.logger" ;)

Atila
Apr 21 2015
parent reply "Robert burner Schadek" <rburners gmail.com> writes:
On Tuesday, 21 April 2015 at 13:18:59 UTC, Atila Neves wrote:

 This part I'd figured out; it's the getting it online for 
 others to see (and the need to do this as part of the PR) I had 
 troubles with.


I did use "github pages" https://pages.github.com/
Apr 21 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-04-21 15:56, Robert burner Schadek wrote:


 I did use "github pages" https://pages.github.com/


I have used dropbox.

-- 
/Jacob Carlborg
Apr 21 2015
prev sibling next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
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:

 Original library: http://code.dlang.org/packages/unit-threaded
 PR: https://github.com/D-Programming-Language/phobos/pull/3207

 It's my first Phobos PR, I tried reading the wiki and doing 
 what's required but bear with me if I've screwed up somehow.

 I wasn't sure whether or not to split the PR. In the end I just 
 took the existing library, edited it a lot and got it ready for 
 review.

 Unit test blocks can be named with  Name. They execute in 
 parallel by default but that's only if the default runner is 
 used.

 Atila
Jun 01 2015
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-06-01 18:38, 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.


I would like to have some more documentation, some more examples how to 
use this.

I think all UDA's should start with a lowercase character.

-- 
/Jacob Carlborg
Jun 01 2015
next sibling parent Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d writes:
On Tue, 02 Jun 2015 08:31:30 +0200
Jacob Carlborg via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On 2015-06-01 18:38, 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.


 
 I would like to have some more documentation, some more examples how
 to use this.
 
 I think all UDA's should start with a lowercase character.
 


I think all UDA's should start with a uppercase character ;-).
(It is much easier to distinguish between UDAs and non-UDAs( nogc,
 safe,  property ...))
Jun 01 2015
prev sibling next sibling parent reply "extrawurst" <stephan extrawurst.org> writes:
On Tuesday, 2 June 2015 at 06:31:14 UTC, Jacob Carlborg wrote:

 On 2015-06-01 18:38, 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.


 I would like to have some more documentation, some more 
 examples how to use this.


Especially the main page needs some more links and at best a 
first example of the kicker features of the package.

By links I mean pure conveniance, see how far down the left the 
package is located :D


 I think all UDA's should start with a lowercase character.
Jun 02 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Tuesday, 2 June 2015 at 08:51:11 UTC, extrawurst wrote:

 On Tuesday, 2 June 2015 at 06:31:14 UTC, Jacob Carlborg wrote:

 On 2015-06-01 18:38, 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.


 I would like to have some more documentation, some more 
 examples how to use this.


 Especially the main page needs some more links and at best a 
 first example of the kicker features of the package.

 By links I mean pure conveniance, see how far down the left the 
 package is located :D


There was an issue with the dlang.org repository and it didn't 
generate the usual navigation on the left. I'll see if it's been 
fixed in the meanwhile and update it.

Like I said before, generating the docs should be a lot easier 
than it is now.

Atila
Jun 02 2015
parent "Atila Neves" <atila.neves gmail.com> writes:
On Tuesday, 2 June 2015 at 09:13:49 UTC, Atila Neves wrote:

 On Tuesday, 2 June 2015 at 08:51:11 UTC, extrawurst wrote:

 On Tuesday, 2 June 2015 at 06:31:14 UTC, Jacob Carlborg wrote:

 On 2015-06-01 18:38, 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.


 I would like to have some more documentation, some more 
 examples how to use this.


 Especially the main page needs some more links and at best a 
 first example of the kicker features of the package.

 By links I mean pure conveniance, see how far down the left 
 the package is located :D


 There was an issue with the dlang.org repository and it didn't 
 generate the usual navigation on the left. I'll see if it's 
 been fixed in the meanwhile and update it.

 Like I said before, generating the docs should be a lot easier 
 than it is now.


Should work now.

Atila
Jun 02 2015
prev sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Tuesday, 2 June 2015 at 06:31:14 UTC, Jacob Carlborg wrote:

 On 2015-06-01 18:38, 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.


 I would like to have some more documentation, some more 
 examples how to use this.


Oh yeah, that's a complaint I heard at DConf. I should definitely 
work on that.


 I think all UDA's should start with a lowercase character.


Why?

Atila
Jun 02 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-06-02 11:12, Atila Neves wrote:


 Why?


Because I think it's looks better :). It's also same standard as the 
built-in attributes are using.

-- 
/Jacob Carlborg
Jun 02 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Tuesday, 2 June 2015 at 19:54:49 UTC, Jacob Carlborg wrote:

 On 2015-06-02 11:12, Atila Neves wrote:


 Why?


 Because I think it's looks better :). It's also same standard 
 as the built-in attributes are using.


Changed them to lower case, added examples and updated the docs.

Atila
Jun 02 2015
parent "ZombineDev" <valid_email he.re> writes:
On Tuesday, 2 June 2015 at 20:50:13 UTC, Atila Neves wrote:

 Changed them to lower case, added examples and updated the docs.

 Atila



The docs look nice. As far as I can tell, this should cover at 
least 75% (for me it is more like 95%) of what people want and is 
not built-in.
Jun 02 2015
prev sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
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
Jun 19 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
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
Jun 22 2015
next sibling parent "Atila Neves" <atila.neves gmail.com> writes:
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
Jun 26 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
Just in case it wasn't clear : I will vote "no" on this proposal 
as long as it features longish "readable" names like 
"shouldEquals".
Jun 26 2015
next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Friday, 26 June 2015 at 13:32:39 UTC, Dicebot wrote:

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


You'd rather `should!"=="`? I'm not sure which I'd prefer; the 
thing is that so far you're the only one strongly against it. The 
only other thing I heard was a question at DConf on why it wasn't 
`assertEquals` instead.

Atila
Jun 26 2015
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 26-Jun-2015 17:30, Atila Neves wrote:

 On Friday, 26 June 2015 at 13:32:39 UTC, Dicebot wrote:

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


 You'd rather `should!"=="`? I'm not sure which I'd prefer; the thing is
 that so far you're the only one strongly against it. The only other
 thing I heard was a question at DConf on why it wasn't `assertEquals`
 instead.


FWIW I totally prefer should!"==" to shouldEquals.

-- 
Dmitry Olshansky
Jun 26 2015
prev sibling parent reply David Gileadi <gileadis NSPMgmail.com> writes:
On 6/26/15 7:30 AM, Atila Neves wrote:

 On Friday, 26 June 2015 at 13:32:39 UTC, Dicebot wrote:

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


 You'd rather `should!"=="`? I'm not sure which I'd prefer; the thing is
 that so far you're the only one strongly against it. The only other
 thing I heard was a question at DConf on why it wasn't `assertEquals`
 instead.

 Atila


Let's paint this bikeshed!

I tend to like "must" instead of "should"; it's a bit shorter and stronger.

I tend to like dot-separated English for testing, e.g.

throwRangeError.must.throw!RangeError;

One advantage is that the dot after "must" (or "should") can trigger 
code completion on IDEs.

Finally, I wonder if it's possible to hijack operator overloading to 
support this:

2.timesTwo.must == 4;
Jun 26 2015
next sibling parent Jacob Carlborg <doob me.com> writes:
On 26/06/15 17:20, David Gileadi wrote:


 Let's paint this bikeshed!

 I tend to like "must" instead of "should"; it's a bit shorter and stronger.


I prefer "should".


 I tend to like dot-separated English for testing, e.g.

 throwRangeError.must.throw!RangeError;

 One advantage is that the dot after "must" (or "should") can trigger
 code completion on IDEs.


It will also be more composeable. Currently there are a couple of 
assertions that have no negative form, i.e. "shouldBeTrue". If 
should/shouldNot would be separate from the actual comparison it would 
be possible to write "shouldNot.beTrue". It could also support custom 
assertions in the future: "should.beA!(Foo)".


 Finally, I wonder if it's possible to hijack operator overloading to
 support this:

 2.timesTwo.must == 4;


Yes and no :). For plain "==" it's possible, but not for ">=" and the 
other greater/less/negative comparisons. All these operators are 
implemented using the same method. Although there's an enhancement 
request (somewhere) to support overloading these operators separately.

-- 
/Jacob Carlborg
Jun 26 2015
prev sibling parent "Atila Neves" <atila.neves gmail.com> writes:
On Friday, 26 June 2015 at 15:20:43 UTC, David Gileadi wrote:

 On 6/26/15 7:30 AM, Atila Neves wrote:

 On Friday, 26 June 2015 at 13:32:39 UTC, Dicebot wrote:

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


 You'd rather `should!"=="`? I'm not sure which I'd prefer; the 
 thing is
 that so far you're the only one strongly against it. The only 
 other
 thing I heard was a question at DConf on why it wasn't 
 `assertEquals`
 instead.

 Atila


 Let's paint this bikeshed!

 I tend to like "must" instead of "should"; it's a bit shorter 
 and stronger.

 I tend to like dot-separated English for testing, e.g.

 throwRangeError.must.throw!RangeError;

 One advantage is that the dot after "must" (or "should") can 
 trigger code completion on IDEs.

 Finally, I wonder if it's possible to hijack operator 
 overloading to support this:

 2.timesTwo.must == 4;


Yes, this works for `==`. Unfortunately it doesn't work for 
anything else, including but not limited to `!=`. Oh, I tried. 
Even though `==` is clearly going to be the most used one, I 
don't like the idea of having to use a compile-time string for 
the other ones.

Atila
Jun 26 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 26/06/15 15:32, Dicebot wrote:

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


You would vote "no" because of this?

-- 
/Jacob Carlborg
Jun 26 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 26 June 2015 at 15:32:47 UTC, Jacob Carlborg wrote:

 On 26/06/15 15:32, Dicebot wrote:

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


 You would vote "no" because of this?


Totally. Remember - this is effectively will make specific API a 
language standard which will propagate it to all sort of 3d party 
libraries. I find it unacceptably unreadable and verbose, to the 
point it will make working with those libraries considerably 
harder.

I use `test!"=="(a. b)` which is:
- short
- robust (supports any binary operator D has)
- straight to the point (it is about testing, not about what 
program should/must do)

The fact that examples uncourage UFCS abuse makes it even worse. 
Something that looks like this:

`2.timesTwo.shouldEqual(4)`

.. gets immediately marked as garbage in my book.

There are also things like `shouldBeFalse` and `shouldBeTrue`. I 
couldn't imagine anyone seriously using names like that until I 
have examined that proposal.
Jun 26 2015
next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Friday, 26 June 2015 at 15:46:28 UTC, Dicebot wrote:

 On Friday, 26 June 2015 at 15:32:47 UTC, Jacob Carlborg wrote:

 On 26/06/15 15:32, Dicebot wrote:

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


 You would vote "no" because of this?


 Totally. Remember - this is effectively will make specific API 
 a language standard which will propagate it to all sort of 3d 
 party libraries. I find it unacceptably unreadable and verbose, 
 to the point it will make working with those libraries 
 considerably harder.

 I use `test!"=="(a. b)` which is:
 - short
 - robust (supports any binary operator D has)
 - straight to the point (it is about testing, not about what 
 program should/must do)

 The fact that examples uncourage UFCS abuse makes it even 
 worse. Something that looks like this:

 `2.timesTwo.shouldEqual(4)`
 .. gets immediately marked as garbage in my book.


Your UFCS abuse is my UFCS awesomeness. It doesn't _make_ you use 
UFCS though, nobody would stop you from writing 
`shouldEqual(timesTwo(2), 4)` instead, which I think is nearly as 
readable. "Nearly" because I prefer UFCS. The advantage of using 
a word like "should" is that it enables UFCS, which "test" 
doesn't. After that it's a question of code style preferences 
whether or not you use it.

Atila
Jun 27 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 27 June 2015 at 16:44:49 UTC, Atila Neves wrote:

 Your UFCS abuse is my UFCS awesomeness. It doesn't _make_ you 
 use UFCS though, nobody would stop you from writing 
 `shouldEqual(timesTwo(2), 4)` instead, which I think is nearly 
 as readable. "Nearly" because I prefer UFCS. The advantage of 
 using a word like "should" is that it enables UFCS, which 
 "test" doesn't. After that it's a question of code style 
 preferences whether or not you use it.


And disagreement about how idiomatic such style preferences 
should be is exactly the reason why I will vote "no".

Look at it this way : if this proposal will never get to Phobos, 
I won't lose anything. It does not have any really important 
utility I need in standard library. Main thing about this 
proposal is making certain testing style standard - and thus 
there is no practical reason to accept any compromises.
Jun 27 2015
next sibling parent "Atila Neves" <atila.neves gmail.com> writes:
On Saturday, 27 June 2015 at 17:37:13 UTC, Dicebot wrote:

 On Saturday, 27 June 2015 at 16:44:49 UTC, Atila Neves wrote:

 [...]


 And disagreement about how idiomatic such style preferences 
 should be is exactly the reason why I will vote "no".

 Look at it this way : if this proposal will never get to 
 Phobos, I won't lose anything. It does not have any really 
 important utility I need in standard library. Main thing about 
 this proposal is making certain testing style standard - and 
 thus there is no practical reason to accept any compromises.


I understand your point. _My_ point is that nobody has to use 
UFCS if they don't want to. In fact, plain asserts could be used 
too.

Atila
Jun 27 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 27/06/15 19:37, Dicebot wrote:


 Main thing about this proposal is making certain
 testing style standard - and thus there is no practical reason to accept
 any compromises.


Great, lets settle with the "should" syntax.

-- 
/Jacob Carlborg
Jun 27 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 26/06/15 17:46, Dicebot wrote:


 Totally. Remember - this is effectively will make specific API a
 language standard which will propagate it to all sort of 3d party
 libraries.


I don't mind :)


 I find it unacceptably unreadable and verbose, to the point
 it will make working with those libraries considerably harder.

 I use `test!"=="(a. b)` which is:
 - short
 - robust (supports any binary operator D has)
 - straight to the point (it is about testing, not about what program
 should/must do)


I would say that using strings as template parameters for everything in 
D is really ugly and a sign of abuse. Soon all D code will be contained 
in a single string literal passed to some function.


 The fact that examples uncourage UFCS abuse makes it even worse.
 Something that looks like this:

 `2.timesTwo.shouldEqual(4)`

 .. gets immediately marked as garbage in my book.


So what do you UFCS should be used for, only for arrays/ranges?


 There are also things like `shouldBeFalse` and `shouldBeTrue`. I
 couldn't imagine anyone seriously using names like that until I have
 examined that proposal.


You need to try Ruby ;)

-- 
/Jacob Carlborg
Jun 27 2015
parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 27 June 2015 at 20:42:52 UTC, Jacob Carlborg wrote:

 `2.timesTwo.shouldEqual(4)`

 .. gets immediately marked as garbage in my book.


 So what do you UFCS should be used for, only for arrays/ranges?


I see two generally legit use cases for UFCS : range pipelines 
and user literals (`42.seconds`). The way it becomes (ab)used 
lately is one of major reasons I like the language now notably 
less than I did ~2 years ago.
Jun 27 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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

* 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 would recommend writing the actual operator used for a given "should 
function" in the documentation

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

* 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

* 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?

-- 
/Jacob Carlborg
Jun 03 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
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
Jun 03 2015
parent reply Jacob Carlborg <doob me.com> writes:
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
Jun 03 2015
parent "Atila Neves" <atila.neves gmail.com> writes:
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
Jun 04 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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

-- 
/Jacob Carlborg
Jun 03 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
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
Jun 03 2015
parent Jacob Carlborg <doob me.com> writes:
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
Jun 03 2015
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Jun 26 2015
parent "Atila Neves" <atila.neves gmail.com> writes:
On Friday, 26 June 2015 at 13:14:40 UTC, Adam D. Ruppe wrote:

 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.


Yeah, I know. If I'm not mistaken you have a library for that but 
I didn't want to introduce a dependency. Doing colour output on 
Windows is just annoying so I left it.

If Phobos had something like that already though...


 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.


I'll see if I can whip some more up.

Atila
Jun 26 2015
prev sibling next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Monday, 20 April 2015 at 13:28:30 UTC, Atila Neves wrote:

 Original library: http://code.dlang.org/packages/unit-threaded
 PR: https://github.com/D-Programming-Language/phobos/pull/3207

 It's my first Phobos PR, I tried reading the wiki and doing 
 what's required but bear with me if I've screwed up somehow.

 I wasn't sure whether or not to split the PR. In the end I just 
 took the existing library, edited it a lot and got it ready for 
 review.

 Unit test blocks can be named with  Name. They execute in 
 parallel by default but that's only if the default runner is 
 used.

 Atila


Bump.
Jul 20 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Monday, 20 July 2015 at 13:20:49 UTC, Atila Neves wrote:

 On Monday, 20 April 2015 at 13:28:30 UTC, Atila Neves wrote:

 Original library: http://code.dlang.org/packages/unit-threaded
 PR: https://github.com/D-Programming-Language/phobos/pull/3207

 It's my first Phobos PR, I tried reading the wiki and doing 
 what's required but bear with me if I've screwed up somehow.

 I wasn't sure whether or not to split the PR. In the end I 
 just took the existing library, edited it a lot and got it 
 ready for review.

 Unit test blocks can be named with  Name. They execute in 
 parallel by default but that's only if the default runner is 
 used.

 Atila


 Bump.


Bumpity bump?
Jul 22 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-07-22 17:05, Atila Neves wrote:


 Bumpity bump?


So, what you're trying to say is that it's time for a vote ;)

-- 
/Jacob Carlborg
Jul 22 2015
parent "Atila Neves" <atila.neves gmail.com> writes:
On Wednesday, 22 July 2015 at 18:46:37 UTC, Jacob Carlborg wrote:

 On 2015-07-22 17:05, Atila Neves wrote:


 Bumpity bump?


 So, what you're trying to say is that it's time for a vote ;)


Are you volunteering to be the review manager? ;)

Atila
Jul 24 2015
prev sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Monday, 20 April 2015 at 13:28:30 UTC, Atila Neves wrote:

 Original library: http://code.dlang.org/packages/unit-threaded
 PR: https://github.com/D-Programming-Language/phobos/pull/3207

 It's my first Phobos PR, I tried reading the wiki and doing 
 what's required but bear with me if I've screwed up somehow.

 I wasn't sure whether or not to split the PR. In the end I just 
 took the existing library, edited it a lot and got it ready for 
 review.

 Unit test blocks can be named with  Name. They execute in 
 parallel by default but that's only if the default runner is 
 used.

 Atila


Looks solid. I'm, shamefully, not a heavy user of unit testing 
but it appears to have everything I typically use from Google 
Test (C++) and is much more friendly to use thanks to the 
reflection and attributes.

What's a scenario where you'd want a hidden test?
Jul 22 2015