www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DUnit: Advanced unit testing toolkit.

reply "Gary Willoughby" <dev nomad.so> writes:
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 documentation). It uses a lot of compile time 
reflection to generate the mocks, which has been very interesting 
to learn/write (to say the least).

I think it's useful enough now to release and it would be nice to 
perhaps receive some guidance as to where it should improve or 
fails spectacularly.

Wikipedia: http://en.wikipedia.org/wiki/Unit_testing

DUnit: https://github.com/kalekold/dunit

See examples and documentation for usage.

Have fun.
Sep 20 2013
next sibling parent "Gary Willoughby" <dev nomad.so> writes:
DUnit has now been added to the DUB registry at 
http://code.dlang.org/.
Sep 21 2013
prev sibling next sibling parent reply "linkrope" <linkrope github.com> writes:
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 fit in?
Sep 22 2013
next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
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 mocks, and the 'must' matchers of specd.

 How does your toolkit fit in?


I looked at DMocks and Specd before i started work on DUnit to 
see what was out there. I'm not saying that DUnit does anything 
really different than those two combined but i'm trying to make 
it simpler to use and more intuitive.

For example DMocks uses an intermediary object to handle the 
mocks. This is thought was a bit strange as this behaviour should 
be in the mock to begin with. So my first objective was to 
provide a way of very simply creating a mock object and to 
interact with that mock object directly. This also fulfilled the 
secondary objective of moving 'setup' code out of the unit test 
and making them more easy to read. Also DUnit solved the problem 
that Dmocks doesn't address of correctly handling Object base 
class methods properly. All methods can fall-through to parent 
implementations or be replaced at runtime.

Specd is a nice approach to defining constraints but again it 
seems overkill for something that should be simple. I don't do 
anything different, i just do it in a different way.

     specd: 1.must.be.greater_than(0);
     dunit: 1.assertGreaterThan(0);

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:

     +------------------------------------------------------------
     | Failed asserting equal
     +------------------------------------------------------------
     | File: example.d
     | Line: 85
     +------------------------------------------------------------
     | ✓ Expected int: 1
     | ✗ Actual int: 2

Making debugging what went wrong loads easier. These messages 
give you so much useful info that you will never go back to only 
using assert() again.
Sep 22 2013
parent "Gary Willoughby" <dev nomad.so> writes:
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:

     
 +------------------------------------------------------------
     | Failed asserting equal
     
 +------------------------------------------------------------
     | File: example.d
     | Line: 85
     
 +------------------------------------------------------------
     | ✓ Expected int: 1
     | ✗ Actual int: 2

 Making debugging what went wrong loads easier. These messages 
 give you so much useful info that you will never go back to 
 only using assert() again.


Actually that should read:

     +------------------------------------------------------------
     | Failed asserting equal
     +------------------------------------------------------------
     | File: example.d
     | Line: 85
     +------------------------------------------------------------
     | ✓ Expected int: 0
     | ✗ Actual int: 1

But you get the idea. ;)
Sep 22 2013
prev sibling next sibling parent reply "jostly" <johan.f.ostling gmail.com> writes:
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 mocks, and the 'must' matchers of specd.


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 shines with the builting facility for unit tests. 
However, it suffers a bit from the fact that, if we use assert, 
it will stop on the first assertion failure, and there is (as far 
as I've been able to tell) no reliable way to run specific code 
before or after all the unit tests. If I'm wrong on that 
assumption, please correct me, that would simplify the spec 
running for specd.

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.

2. Asserting results

Varies from the builtin assert() to xUnit-like assertEquals() to 
the more verbose x.must.equal(y) used in specd.

This could easily be standardized by letting all custom asserts 
throw an AssertError, though I would prefer to use another 
exception that encapsulates the expected and actual result, to 
help with bridging to reporting.

3. Reporting results

If we have moved beyond basic assert() and use some kind of unit 
test runner, then we have the ability to report a summary of run 
tests, and which (and how many) failed.

This is one area where IDE integration would be very nice, and I 
would very much prefer it if the different unit test frameworks 
agreed on one standard unit test runner interface, so that the 
IDE integration problem becomes one of adapting each IDE to one 
runner interface, instead of adapting each framework to each IDE.

In my experience from the Java and Scala world, the last point is 
the biggest. Users expect to be able to run unit tests and see 
the report in whatever standard way their IDE has. In practice 
this most often means that various libraries pretend to be JUnit 
when it comes to running tests, because JUnit is supported by all 
IDEs.

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. :)
Sep 23 2013
next sibling parent "Dicebot" <public dicebot.lv> writes:
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.


I think more "D-way" would have been to simply separate tests in 
logically separated unittest blocks and run those using static 
reflection, catching assert error. That way you will get first 
failure in a set and then continue to other sets. Does that make 
sense?
Sep 23 2013
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
On Mon, 2013-09-23 at 18:40 +0200, jostly wrote:
[=E2=80=A6]

 I think it's great to see the D unit testing ecosystem growing.=20
 Since it's still relatively small, I think we have a good chance=20
 here to create interoperability between the different frameworks.


There is also integration and system testing of course, not just unit
testing. The same testing framework can generally be used for all forms.

In the Java sphere, JUnit gave way to TestNG exactly because TestNG
supports all forms of testing not just unit testing. Now though TestNG
is giving way to Spock enabling elements of BDD as well as TDD.

D has some unit testing capability built in, which i good, but it is
also good to have an external testing framework that can do unit,
integration and system testing supporting TDD and BDD.=20


 As I see it, we have:
=20
 1. Running unit tests
=20
 This is where D shines with the builting facility for unit tests.=20
 However, it suffers a bit from the fact that, if we use assert,=20
 it will stop on the first assertion failure, and there is (as far=20
 as I've been able to tell) no reliable way to run specific code=20
 before or after all the unit tests. If I'm wrong on that=20
 assumption, please correct me, that would simplify the spec=20
 running for specd.


So the built-in is not entirely up to the task of real unit testing?


 In specd, the actual code inside the unittest { } sections only=20
 collect results, and the reporting is called from a main()=20
 supplied by compiling with version "specrunner" set. I haven't=20
 checked to see if your dunit do something similar.
=20
 2. Asserting results
=20
 Varies from the builtin assert() to xUnit-like assertEquals() to=20
 the more verbose x.must.equal(y) used in specd.


In the Scala variant of the JVM arena, ScalaTest mingles really nicely
all the classic TDD asserts styles, along with Hamcrest matchers, but
also supports the more BDD style test specifications. Spock also does
this. Corollary, D must do this.

NB Go is going through all this just now. The built in unit test
capability is minimalist and for testing the Go implementation. GoCheck
is classic TDD assert style, and there are some candidate BDD styles on
the horizon. Will Go beat D to having the capability that the JVM
languages already enjoy?

Note that Groovy and the py.test Python test framework dispense with the
need for assertEquals and that family of JUnit thingies, in favour of
using the built-in assert and catching the AssertionError exception,
doing detailed stack analysis and provided very detailed information
about the evaluated expression: power asserts. Why should D follow 1990s
thinking when there is 2010s thinking that is much better?


 This could easily be standardized by letting all custom asserts=20
 throw an AssertError, though I would prefer to use another=20
 exception that encapsulates the expected and actual result, to=20
 help with bridging to reporting.


See above :-)


 3. Reporting results
=20
 If we have moved beyond basic assert() and use some kind of unit=20
 test runner, then we have the ability to report a summary of run=20
 tests, and which (and how many) failed.
=20
 This is one area where IDE integration would be very nice, and I=20
 would very much prefer it if the different unit test frameworks=20
 agreed on one standard unit test runner interface, so that the=20
 IDE integration problem becomes one of adapting each IDE to one=20
 runner interface, instead of adapting each framework to each IDE.
=20
 In my experience from the Java and Scala world, the last point is=20
 the biggest. Users expect to be able to run unit tests and see=20
 the report in whatever standard way their IDE has. In practice=20
 this most often means that various libraries pretend to be JUnit=20
 when it comes to running tests, because JUnit is supported by all=20
 IDEs.
=20
 Let's not end up in that situation, but rather work out a common=20
 API to run unit tests, and the D unit test community can be the=20
 envy of every other unit tester. :)


Currently, and very sadly, this generally means writing an XML file
using the JUnit schema. On the other hand if D did this Eclipse, IDEA,
NetBeans, etc. would immediately render excellent data displays.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Sep 23 2013
prev sibling next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
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 
think we are missing some way of knowing when unit tests start 
and stop. I like the built in unittest blocks but it would be 
nice to have something like:

     beforetests
     {
         ...
     }

     aftertests
     {
         ...
     }

To apply code before and after the unit tests have run. These 
could be used to setup and the execute the reporting environment? 
I can't think of a way to do this automatically without these 
constructs.
Sep 23 2013
next sibling parent Rory McGuire <rjmcguire gmail.com> writes:
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 feel like and you could stick with the -unittest dmd arg.
Reason for the thread is you can't control order of module initialization.
On 23 Sep 2013 21:30, "Gary Willoughby" <dev nomad.so> wrote:


 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 think we
 are missing some way of knowing when unit tests start and stop. I like the
 built in unittest blocks but it would be nice to have something like:

     beforetests
     {
         ...
     }

     aftertests
     {
         ...
     }

 To apply code before and after the unit tests have run. These could be
 used to setup and the execute the reporting environment? I can't think of a
 way to do this automatically without these constructs.
Sep 23 2013
prev sibling parent Rory McGuire <rjmcguire gmail.com> writes:
Sorry in my last mail host should be unittest (swype auto correct errors
:))
Sep 23 2013
prev sibling next sibling parent "linkrope" <linkrope github.com> writes:
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 tests

 This is where D shines with the builting facility for unit 
 tests. However, it suffers a bit from the fact that, if we use 
 assert, it will stop on the first assertion failure, and there 
 is (as far as I've been able to tell) no reliable way to run 
 specific code before or after all the unit tests. If I'm wrong 
 on that assumption, please correct me, that would simplify the 
 spec running for specd.

 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.


In my understanding, D's built-in support for unittests is best 
suited for test cases that can be expressed as one-liners. When 
it gets more complicated, we usually use classes. That's what 
JUnit and TestNG do and that's what dunit does (this one: 
https://github.com/linkrope/dunit).

For our software, we even separate the 'src' tree from the 
'unittest' tree to not distort the coverage results.


 2. Asserting results

 Varies from the builtin assert() to xUnit-like assertEquals() 
 to the more verbose x.must.equal(y) used in specd.

 This could easily be standardized by letting all custom asserts 
 throw an AssertError, though I would prefer to use another 
 exception that encapsulates the expected and actual result, to 
 help with bridging to reporting.


It's too easy to use 'assertEquals' wrong. JUnit defines 
'assertEquals(expected, actual)' while DUnit defines it the other 
way around. For JUnit, I've seen too many wrong uses: 
'assertEquals(answer, 42)' giving misleading messages "expected 
... but got 42".

Even with UFCS, why shouldn't you write '42.assertEqual(actual)'? 
That's where the "more verbose" 'must' matchers shine: 
'42.must.equal(actual)' is obviously the wrong way around.

When you have violated contracts, you get 'AssertError' 
exceptions from deep within your code under test. To fix these 
errors you may wish for a stack trace. On the other hand, the 
pretty messages you get for failed test assertions should be 
enough to fix these failures. In this case, the stack trace would 
only show the test runner calling the test case.

So: 'must' matchers are better than 'assert...'; and 
'AssertError' should not be thrown for failures!


 3. Reporting results

 If we have moved beyond basic assert() and use some kind of 
 unit test runner, then we have the ability to report a summary 
 of run tests, and which (and how many) failed.

 This is one area where IDE integration would be very nice, and 
 I would very much prefer it if the different unit test 
 frameworks agreed on one standard unit test runner interface, 
 so that the IDE integration problem becomes one of adapting 
 each IDE to one runner interface, instead of adapting each 
 framework to each IDE.

 In my experience from the Java and Scala world, the last point 
 is the biggest. Users expect to be able to run unit tests and 
 see the report in whatever standard way their IDE has. In 
 practice this most often means that various libraries pretend 
 to be JUnit when it comes to running tests, because JUnit is 
 supported by all IDEs.


A few days ago, I added such a reporting to dunit. An XML test 
report is now available that uses the JUnitReport format. We use 
Jenkins (formerly known as Hudson) for continuous integration so 
that we can browse our test results and track failures. Nice!


 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. :)


Agreed!
Sep 24 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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 shines with the builting facility for unit tests.
 However, it suffers a bit from the fact that, if we use assert, it will
 stop on the first assertion failure, and there is (as far as I've been
 able to tell) no reliable way to run specific code before or after all
 the unit tests. If I'm wrong on that assumption, please correct me, that
 would simplify the spec running for specd.

 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.


Agree. I only see the unittest blocks as a place to but the asserts, 
since it's not possible to put them at module level.

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-Programming-Language/druntime/blob/master/src/core/exception.d#L368

But you most likely want to throw some kind of exception anyway. Because 
if an assertion is triggered in a unit test block you most likely want 
to end that unit test block, immediately.

-- 
/Jacob Carlborg
Sep 24 2013
next sibling parent reply "jostly" <johan.f.ostling gmail.com> writes:
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 missing link between what I want to do and what I thought was 
possible.


 But you most likely want to throw some kind of exception 
 anyway. Because if an assertion is triggered in a unit test 
 block you most likely want to end that unit test block, 
 immediately.


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 the unit test block, instead 
of wrapped inside delegates like it's done in specd. Ideally, a 
generic runner would support both immediate and deferred tests.
Sep 25 2013
parent reply "Dicebot" <public dicebot.lv> writes:
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 the 
 unit test block, instead of wrapped inside delegates like it's 
 done in specd. Ideally, a generic runner would support both 
 immediate and deferred tests.


UDAs + recent trait to get all unit-tests during compile-time 
really favors instead having lot of small independent annotated 
unit-test blocks.
Sep 25 2013
parent reply Jacob Carlborg <doob me.com> writes:
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 order. Example:

unittest
{
      test("foo")
     {
         assert(1 == 1);
     }

      test("bar")
     {
         assert(1 == 2);
     }
}

You cannot run "foo" separated from "bar". They all will always run 
together. You also cannot run "bar" before running "foo". Running tests 
like this makes it very easy to introduce order dependencies between the 
tests.

-- 
/Jacob Carlborg
Sep 25 2013
parent reply "Dicebot" <public dicebot.lv> writes:
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 test block you always 
 need to run them together, and in the declared order. Example:

 unittest
 {
      test("foo")
     {
         assert(1 == 1);
     }

      test("bar")
     {
         assert(1 == 2);
     }
 }

 You cannot run "foo" separated from "bar". They all will always 
 run together. You also cannot run "bar" before running "foo". 
 Running tests like this makes it very easy to introduce order 
 dependencies between the tests.


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 first failure. That 
should integrate better with existing tooling when no external 
testing library/framework is connected.
Sep 26 2013
parent reply Jacob Carlborg <doob me.com> writes:
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 first failure. That should
 integrate better with existing tooling when no external testing
 library/framework is connected.


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.

-- 
/Jacob Carlborg
Sep 26 2013
parent reply "Dicebot" <public dicebot.lv> writes:
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 
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 testing frameworks do.

Key point here is that good testing library should augment 
built-in facility, not replace it. Fallback to built-ins can 
still be useful.
Sep 26 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
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 testing frameworks do.


Ok, I see. Yes, there are some libraries that does that.


 Key point here is that good testing library should augment built-in
 facility, not replace it. Fallback to built-ins can still be useful.



-- 
/Jacob Carlborg
Sep 26 2013
prev sibling parent "Atila Neves" <atila.neves gmail.com> writes:
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. 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 
 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 testing frameworks do.

 Key point here is that good testing library should augment 
 built-in facility, not replace it. Fallback to built-ins can 
 still be useful.
Sep 26 2013
prev sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
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-Programming-Language/druntime/blob/master/src/core/exception.d#L368

 But you most likely want to throw some kind of exception 
 anyway. Because if an assertion is triggered in a unit test 
 block you most likely want to end that unit test block, 
 immediately.


That looks interesting but the unittester handler seems to run 
instead of the unittest blocks and the assert handler property is 
private.
Sep 25 2013
parent reply "Jacob Carlborg" <doob me.com> writes:
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 a 
single function for each module, which will call all these unit 
test functions. If you access the "unitTest" [1] property of a 
ModuleInfo you will get the unit test runner and not the 
individual unit test functions.

To access the individual unit test functions you can use the 
getUnitTests trait, available in git HEAD:

https://github.com/D-Programming-Language/dlang.org/pull/366


 and the assert handler property is private.


There are property functions at line 374 and below to set the 
assert handler.

[1] 
https://github.com/D-Programming-Language/druntime/blob/master/src/object.di#L284

--
/Jacob Carlborg
Sep 25 2013
parent reply "Gary Willoughby" <dev nomad.so> writes:
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) 
AssertHandler;

AssertHandler handler = function(string file, size_t line, string 
msg)
{
	writefln("File: %s", file);
	writefln("Line: %s", line);
	writefln("Message: %s", msg);
};

void main(string[] args)
{
	// assertHandler = handler; // <--- Private!
	setAssertHandler(handler); // <--- Works but deprecated

	assert(false, "Test message.");
}
Sep 26 2013
parent reply Jacob Carlborg <doob me.com> writes:
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("File: %s", file);
      writefln("Line: %s", line);
      writefln("Message: %s", msg);
 };

 void main(string[] args)
 {
      // assertHandler = handler; // <--- Private!
      setAssertHandler(handler); // <--- Works but deprecated

      assert(false, "Test message.");
 }


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/exception.d#L380

-- 
/Jacob Carlborg
Sep 26 2013
parent reply "Gary Willoughby" <dev nomad.so> writes:
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/exception.d#L380


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.
Sep 26 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Sep 26 2013
parent reply "Gary Willoughby" <dev nomad.so> writes:
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 using DMD 2.063.2 on Mac OS X.


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.
Sep 27 2013
parent reply Jacob Carlborg <doob me.com> writes:
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, ok, you were right. The following commit made it public:

d5fda766c248b5b3671b1b498c0a7dba8bee7442

I guess we'll have to wait to the next release of DMD or use git HEAD.

-- 
/Jacob Carlborg
Sep 28 2013
parent "Gary Willoughby" <dev nomad.so> writes:
Updated DUnit with some refactored code and started to implement 
a results module.
Sep 29 2013
prev sibling parent "Atila Neves" <atila.neves gmail.com> writes:
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!
Sep 26 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
 documentation). It uses a lot of compile time reflection to generate the
 mocks, which has been very interesting to learn/write (to say the least).

 I think it's useful enough now to release and it would be nice to
 perhaps receive some guidance as to where it should improve or fails
 spectacularly.

 Wikipedia: http://en.wikipedia.org/wiki/Unit_testing

 DUnit: https://github.com/kalekold/dunit

 See examples and documentation for usage.

 Have fun.


You might want to use alternatively you could use "version(unittest)" 
instead of "debug" for the mocks. Don't know which is better.

-- 
/Jacob Carlborg
Sep 22 2013
prev sibling next sibling parent "linkrope" <linkrope github.com> writes:
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, you can do the same for 'assertStartsWith' and 
'assertEndsWith'?
Sep 24 2013
prev sibling parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
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 (mostly due to poor documentation). It uses a lot of 
 compile time reflection to generate the mocks, which has been 
 very interesting to learn/write (to say the least).


Guys, we have at least 5 (!) different unit test projects!
Can you cooperate your efforts to create one, but wonderful?
Oct 06 2013
parent reply "Gary Willoughby" <dev nomad.so> writes:
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 
 the community here for helping me with a few issues along the 
 way (mostly due to poor documentation). It uses a lot of 
 compile time reflection to generate the mocks, which has been 
 very interesting to learn/write (to say the least).


 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 all approaching the same 
problem from different angles. I'm sure in the long run one or 
two will grow to be dominant but in the meantime many will ensure 
healthy competition on features and completeness.
Oct 06 2013
parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
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 all approaching the 
 same problem from different angles. I'm sure in the long run 
 one or two will grow to be dominant but in the meantime many 
 will ensure healthy competition on features and completeness.


OK, maybe you are right.
Do you have any plans to integrate your code into Phobos?
Oct 06 2013
parent "Gary Willoughby" <dev nomad.so> writes:
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.
Oct 07 2013