On Sunday, 6 October 2013 at 14:24:56 UTC, ilya-stromberg wrote:
OK, maybe you are right.
Do you have any plans to integrate your code into Phobos?
Nah, a unit testing framework is not really standard lib material.
On Sunday, 6 October 2013 at 10:36:08 UTC, Gary Willoughby wrote:
On Sunday, 6 October 2013 at 07:32:09 UTC, ilya-stromberg wrote:
Guys, we have at least 5 (!) different unit test projects!
Can you cooperate your efforts to create one, but wonderful?
I think it's good to have many as we are al
On Sunday, 6 October 2013 at 07:32:09 UTC, ilya-stromberg wrote:
On Saturday, 21 September 2013 at 00:40:47 UTC, Gary Willoughby
wrote:
DUnit: Advanced unit testing toolkit.
I've needed this for a project i've been working on so i
created a toolkit that i'm using and happy with. I must thank
On Saturday, 21 September 2013 at 00:40:47 UTC, Gary Willoughby
wrote:
DUnit: Advanced unit testing toolkit.
I've needed this for a project i've been working on so i
created a toolkit that i'm using and happy with. I must thank
the community here for helping me with a few issues along the
way
Updated DUnit with some refactored code and started to implement
a results module.
On 2013-09-27 18:23, Gary Willoughby wrote:
I've just tested it on Mac OS 10.8 and it fails.
Are you sure you commented out the line of code that you need to test?
In the snippet of code above the working deprecated version is
uncommented. Comment that line out and try using the property.
Hmm
On Friday, 27 September 2013 at 06:28:54 UTC, Jacob Carlborg
wrote:
On 2013-09-26 22:39, Gary Willoughby wrote:
I knowm, it's weird, i've been trying to find out why it's
private,
everything looks like it's public. Try running the code i
posted see if
you can get it to work.
It works fine u
On 2013-09-26 22:39, Gary Willoughby wrote:
I knowm, it's weird, i've been trying to find out why it's private,
everything looks like it's public. Try running the code i posted see if
you can get it to work.
It works fine using DMD 2.063.2 on Mac OS X.
--
/Jacob Carlborg
My library, unit-threaded, does just that. All unittest blocks
from a module show up as one test case in the output.
On Thursday, 26 September 2013 at 14:56:49 UTC, Dicebot wrote:
On Thursday, 26 September 2013 at 14:51:16 UTC, Jacob Carlborg
wrote:
Exactly. I guess I misunderstood you. Althoug
On Sunday, 22 September 2013 at 13:13:29 UTC, linkrope wrote:
Have a look at https://github.com/linkrope/dunit, especially at
the "Related Projects".
Thanks for the link to
https://github.com/atilaneves/unit-threaded!
On Thursday, 26 September 2013 at 19:25:46 UTC, Jacob Carlborg
wrote:
I don't know which version of DMD you're using or when this
part of druntime was update, but it's clearly not private
according to the source code:
https://github.com/D-Programming-Language/druntime/blob/master/src/core/exce
On 2013-09-26 20:18, Gary Willoughby wrote:
Only the deprecated version works as expected.
import core.exception;
import std.stdio;
alias void function(string file, size_t line, string msg) AssertHandler;
AssertHandler handler = function(string file, size_t line, string msg)
{
writefln("
On 2013-09-26 16:56, Dicebot wrote:
Beg my pardon, bad wording from my side. I was referring to approach
when testing framework defines some sort of own testing DSL and uses it
for test case decoupling within one unit-test block - as far as I
understand it is what some of currently existing D te
On Wednesday, 25 September 2013 at 21:00:00 UTC, Jacob Carlborg
wrote:
There are property functions at line 374 and below to set the
assert handler.
Only the deprecated version works as expected.
import core.exception;
import std.stdio;
alias void function(string file, size_t line, string msg
On Thursday, 26 September 2013 at 14:51:16 UTC, Jacob Carlborg
wrote:
Exactly. I guess I misunderstood you. Although I would consider
"having lot of small independent annotated unit-test blocks" be
basically what you're showing above.
Beg my pardon, bad wording from my side. I was referring to
On 2013-09-26 13:12, Dicebot wrote:
I was saying that if you want to have some tests independent, it makes
much more sense to do it this way:
```
@test("foo") unittest
{
assert(1 == 1);
}
@test("bar") unittest
{
assert(1 == 2);
}
```
..and let tests within one block terminate on fir
On Thursday, 26 September 2013 at 06:07:50 UTC, Jacob Carlborg
wrote:
On 2013-09-25 21:55, Dicebot wrote:
UDAs + recent trait to get all unit-tests during compile-time
really
favors instead having lot of small independent annotated
unit-test blocks.
If you have more than one test per unit te
On 2013-09-25 21:55, Dicebot wrote:
UDAs + recent trait to get all unit-tests during compile-time really
favors instead having lot of small independent annotated unit-test blocks.
If you have more than one test per unit test block you always need to
run them together, and in the declared orde
On Wednesday, 25 September 2013 at 20:18:57 UTC, Gary Willoughby
wrote:
That looks interesting but the unittester handler seems to run
instead of the unittest blocks
I'm not exactly sure what you mean. But this is how it works. DMD
turns each unit test block into a function. Then DMD creates
On Wednesday, 25 September 2013 at 06:45:12 UTC, Jacob Carlborg
wrote:
It's possible to implement you're own unit test handler. See:
https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L290
It's also possibly to set the assert handler:
https://github.com/D-Program
On Wednesday, 25 September 2013 at 19:50:47 UTC, jostly wrote:
Maybe... in my mind it depends on whether there are more than
one test per unit test block, because I really like each
failing test to be enumerated as well. But I can see the
benefit - that would allow me to have tests directly in
On Wednesday, 25 September 2013 at 06:45:12 UTC, Jacob Carlborg
wrote:
It's possible to implement you're own unit test handler. See:
https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L290
This changes everything! Thanks for that pointer, it really was
the missi
On 2013-09-23 18:40, jostly wrote:
I think it's great to see the D unit testing ecosystem growing. Since
it's still relatively small, I think we have a good chance here to
create interoperability between the different frameworks.
As I see it, we have:
1. Running unit tests
This is where D shi
Same hint as for specd: have a look at 'assertOp'!
http://d.puremagic.com/issues/show_bug.cgi?id=4653
alias assertOp!">" assertGreaterThan;
alias assertOp!">=" assertGreaterThanOrEqual;
alias assertOp!"<" assertLessThan;
alias assertOp!"<=" assertLessThanOrEqual;
avoids duplicate code.
Maybe, y
On Monday, 23 September 2013 at 16:40:56 UTC, jostly wrote:
I think it's great to see the D unit testing ecosystem growing.
Since it's still relatively small, I think we have a good
chance here to create interoperability between the different
frameworks.
As I see it, we have:
1. Running unit
Sorry in my last mail host should be unittest (swype auto correct errors
:))
Can you not just change to going through each module running the hosts
manually? Then you can do what you like before and after each.
If your lib had a host that started a thread which received messages about
a unittest registering itself in other user modules you could run the
unittests as you
On Monday, 23 September 2013 at 16:40:56 UTC, jostly wrote:
Let's not end up in that situation, but rather work out a
common API to run unit tests, and the D unit test community can
be the envy of every other unit tester. :)
You've raised some nice ideas and got me thinking. However, i do
thi
On Mon, 2013-09-23 at 18:40 +0200, jostly wrote:
[…]
> I think it's great to see the D unit testing ecosystem growing.
> Since it's still relatively small, I think we have a good chance
> here to create interoperability between the different frameworks.
There is also integration and system testi
On Sunday, 22 September 2013 at 13:13:29 UTC, linkrope wrote:
Have a look at https://github.com/linkrope/dunit, especially at
the "Related Projects".
Until now, my preferred tool for (large-scale) unit testing in D
would be the combination of my dunit framework (of course),
DMocks-revived for mo
On Monday, 23 September 2013 at 16:40:56 UTC, jostly wrote:
In specd, the actual code inside the unittest { } sections only
collect results, and the reporting is called from a main()
supplied by compiling with version "specrunner" set. I haven't
checked to see if your dunit do something similar
On 2013-09-21 02:40, Gary Willoughby wrote:
DUnit: Advanced unit testing toolkit.
I've needed this for a project i've been working on so i created a
toolkit that i'm using and happy with. I must thank the community here
for helping me with a few issues along the way (mostly due to poor
documenta
On Sunday, 22 September 2013 at 15:54:39 UTC, Gary Willoughby
wrote:
The reason i've gone with just providing more specific assert
methods is that i can create nice helpful error message when
things go wrong. For example this line:
1.assertEquals(0);
Creates this error:
+---
On Sunday, 22 September 2013 at 13:13:29 UTC, linkrope wrote:
Have a look at https://github.com/linkrope/dunit, especially at
the "Related Projects".
Until now, my preferred tool for (large-scale) unit testing in D
would be the combination of my dunit framework (of course),
DMocks-revived for mo
Have a look at https://github.com/linkrope/dunit, especially at
the "Related Projects".
Until now, my preferred tool for (large-scale) unit testing in D
would be the combination of my dunit framework (of course),
DMocks-revived for mocks, and the 'must' matchers of specd.
How does your toolkit f
DUnit has now been added to the DUB registry at
http://code.dlang.org/.
36 matches
Mail list logo
