On Sunday, 18 March 2012 at 11:05:59 UTC, Marc P. Michel wrote:
> Oh and also, changing "version(linux)" with "version(Posix)" for the color output management would be great. ( I'm on FreeBSD and was wondering why I had no colors as advertised :} ).

Yeahp, will fix it. Sorry!

Thanks for finding that!

Still haven't had the time to get back to dunit,
but I will eventually, and also make a proper documentation.

  I'm also going to make the whole family of assert functions,
(assertNotNull, assertNotEquals, etc.) but I'm not sure where
to put the optional 'message' argument (first or last).
To be compatible with the java style, 'message' would go first.
But that would have two issues:

  - It's different than D's assert where 'message' goes last.

  - "assertNotNull(someStr, "message");" would compile and you
    wouldn't have a clue that "message" was supposed to go
    as first argument.

Btw, here is the whole list:
    http://www.junit.org/junit/javadoc/3.8.1/junit/framework/Assert.html


Do you have any thoughts?

--jm

On Wednesday, 21 March 2012 at 17:29:59 UTC, Juan Manuel Cabo
wrote:
> Btw, here is the whole list:
>     http://www.junit.org/junit/javadoc/3.8.1/junit/framework/Assert.html
>
>
> Do you have any thoughts?

Be careful: for JUnit 4 there is a separation of concerns.

The assertions are now the responsibility of the Hamcrest
library: http://code.google.com/p/hamcrest/
(Wouldn't it be nice to have a port to D?)

On the other hand, D/JUnit "just" provides the frame for the test
cases.

Here are some ideas for this DUnit frame (from the previous
DUnit):
- provide means to let a test case pass iff an expected exception
is thrown
- use command-line args to filter test cases to be executed
- add an XML test report for inspection by machines

On Wednesday, 21 March 2012 at 20:04:39 UTC, Rio wrote:
> On Wednesday, 21 March 2012 at 17:29:59 UTC, Juan Manuel Cabo
> wrote:
>> Btw, here is the whole list:
>>    http://www.junit.org/junit/javadoc/3.8.1/junit/framework/Assert.html
>>
>>
>> Do you have any thoughts?
>
> Be careful: for JUnit 4 there is a separation of concerns.
>
> The assertions are now the responsibility of the Hamcrest
> library: http://code.google.com/p/hamcrest/
> (Wouldn't it be nice to have a port to D?)

Not true.
Regular asserts are still regular asserts in junit4.
Hamcrest is supported for other kinds of asserts.

The only care taken must be to consider an assert as something
that throws core.exception.AssertError, which is already done.
You can create your own kinds of asserts.

Also, for mock objects, take a look at BlackHole and WhiteHole
in std.typecons. That, together with anonymous classes pretty much
is all you need for basic mock objects for testing.


>
> On the other hand, D/JUnit "just" provides the frame for the test
> cases.

Exactly.

>
> Here are some ideas for this DUnit frame (from the previous
> DUnit):
> - provide means to let a test case pass iff an expected exception is thrown

You already have it: std.exception.assertThrown().


> - use command-line args to filter test cases to be executed

Nice, I'll implement in the DUnitMain mixin.


> - add an XML test report for inspection by machines

Not big on the priority list, but yes, some kind of automation
for Ant and IDEs would be cool. The reason I tried to stay
compatible with java style tests output is so that some existing
tools might already be able to parse it.
   For xml output, I would layout the output in some form that is
already recognized by tools, and that would take me some time.
And this DUnit is still too green (but 100% solid and usable in
what it provides).
   I first want to do a graphical test runner.
I also want to have the runner precompiled outside.
So that I can stay in the test runner window, and just click
'retest' after recompiling. I got very used to this rhythm
of work, and I think it'd be nice to have it in D. For
that to work, I have to solve a few issues.

Also, I don't want to make a graphical test runner that
only works on windows or only works on unix. And I love DWT,
so I first want a DWT that everyone can depend on.
I already made DWT compile in linux 64bit which didn't work
(though not as a library, that had some issues of its own,
instead, I have to list aaalll the DWT files used in the
dmd command line).

So my priorities are (for when I have time!!):

     -Merge to latest DWT (I diverged last year when dmd 2.0.54
      was newest) and make a pull request for DWT.

     -Add more assert* to DUnit, finalizing its API so to speak.
      Any other future DUnit change will be source compatible.
      (at least until D gets user defined attributes!).

     -Solve the 'test runner compiled outside' issues.

     -Make a graphical test runner, the nicest, slickest,
      coolest one of the *Unit bunch!!

--jm

alive dans ton petit village?

How do I test callbacks/delegates which are not triggered immediately? Especially when I need to do unit tests with an event loop?
A simple example from my codebase (SaaSy here is a custom HTTP client to an API endpoint):

class TestSaaSy {
    mixin TestMixin;

    // this works
    void test_encoded_auth() {
        auto ev = new EventLoop;
        auto saasy = new SaaSy(ev, "test", "test");
        assert(saasy.encoded_auth == "dGVzdDp0ZXN0dGVzdA==", "encoding issue");
        ev.close;
        ev.run;
    }

    // won't work. test gets finished even before the callback is fired!
    void test_get_subscription() {
        auto ev = new EventLoop;
        auto saasy = new SaaSy(ev, "test", "test");
        saasy.getSubscription("ref363466", (bool err, string response) {
            assert(err == true);
            ev.close;
        });
        ev.run;
    }
}

On Sunday, 19 February 2012 at 15:30:33 UTC, Juan Manuel Cabo wrote:
> People of the D world.. I give you DUnit (not to be confused with an old
> tango DUnit, this one is for >= D2.057, and doesn't really require phobos or tango (just you version the few writeln's of the runner, and maybe
> something else)).
>
>       https://github.com/jmcabo/dunit
>
> I've been developing it for the past few weeks, and since I saw a post of another unit testing framework just a few minutes ago, I thought I'd rush it to github.
>
> Soooo, here is how you define a test:
>
>
> import dunit;
>
> class Something {
>     mixin TestMixin;
>
>     void testOne() {
>         assert(1 == 1, "this works");
>     }
>
>     void testTwo() {
>         assertEquals(1, 2/2);
>         assertEquals("a string", "a"~" string");
>     }
> }
>
> .. and that's all there is to it. Put the mixin TestMixin, and name your tests
> starting with 'test'. The results output shows all of them even if some fail, and... guess what, it tells you the name of the unit tests that failed!! isn't this awesome!! (all thanks to mixins, recursive template declarations, __traits, and a little bit of CTFE)... isn't D like, so incredibly awesome or what!?!?
>
> There is absolutely no overhead in registering the tests for the test runner.. its all at compile time!
>
> Your tests are inherited through derived classes, and can be private in the unit test class (they will still run).
>
>
> I made two test runners:
>
>     * One that shows the results in java style (but WITH COLORS!! (fineprint: colors only on unix console, windows console is colorless for now)
>
>     * Another one more verbose that shows the tree of tests as it runs them.
>
> It is very easy to make your own.
>
>
> This is all BOOST licenced, so please tweak it away!
>
>
> FINEPRINT yes shouting fineprint ;-) haha:
> THIS IS NOT A unitest{} REPLACEMENT, JUST AN ITCH EVERY OOP PEOPLE WANTED TO SCRATCH: named, easy, xUnit style unit tests.. AND NOW YOU'VE GOT THEM.

Just for your information, the name "DUnit" is already used by Delphi.
Probably, you should name it "D2Unit" or "MarsUnit" ?

Add some variable to the test case: bool finished;
Set the variable in the callback: finished = true;
Add something like

    assertWithTimeout({return finished;});

at the end of the test case, following ev.run;

Does it help?

On Wednesday, 29 August 2012 at 19:20:25 UTC, Shripad K wrote:
> How do I test callbacks/delegates which are not triggered immediately? Especially when I need to do unit tests with an event loop?
> A simple example from my codebase (SaaSy here is a custom HTTP client to an API endpoint):
>
> class TestSaaSy {
>     mixin TestMixin;
>
>     // this works
>     void test_encoded_auth() {
>         auto ev = new EventLoop;
>         auto saasy = new SaaSy(ev, "test", "test");
>         assert(saasy.encoded_auth == "dGVzdDp0ZXN0dGVzdA==", "encoding issue");
>         ev.close;
>         ev.run;
>     }
>
>     // won't work. test gets finished even before the callback is fired!
>     void test_get_subscription() {
>         auto ev = new EventLoop;
>         auto saasy = new SaaSy(ev, "test", "test");
>         saasy.getSubscription("ref363466", (bool err, string response) {
>             assert(err == true);
>             ev.close;
>         });
>         ev.run;
>     }
> }

Sorry for the late reply. I thought I would be notified via mail of your reply but I don't think this forum sends alerts. Thanks for this suggestion. However its a bit different in the case of event loops (unlike threads, where a thread.start() would spawn a new thread and bring the control back to the calling block). The ev.run is blocking. So any code in the block that contains ev.run will not get executed if placed after the ev.run line.

It would be great if the tests themselves end manually via asserts themselves and the final report is displayed after collecting results from all asserts.