Here is the 'dunit' mentioned in the talk by Stefan Rohe:
https://github.com/linkrope/dunit

D-stroy ;-)

On 06/12/2013 07:15 PM, Mario Kroeplin wrote:
> Here is the 'dunit' mentioned in the talk by Stefan Rohe: https://github.com/linkrope/dunit
> 
> D-stroy ;-)

I'm glad that dunit was of use to you and that the fork
went well.
I'm sorry I couldn't follow up on it.

--jm

Mario Kroeplin:

> Here is the 'dunit' mentioned in the talk by Stefan Rohe:
> https://github.com/linkrope/dunit
>
> D-stroy ;-)

In that code have you felt the lack for some built-in feature for D (Like some introspection, some hooks, some dynamic feature, etc)?


Maybe you can replace code like this:

final switch (color)
            {
                case Color.red:


With code like:

final switch (color) with (Color)
            {
                case red:


Bye,
bearophile

On Thu, 2013-06-13 at 00:15 +0200, Mario Kroeplin wrote:
> Here is the 'dunit' mentioned in the talk by Stefan Rohe: https://github.com/linkrope/dunit
> 
> D-stroy ;-)

One immediate issue, why have assertArrayEquals distinct from assertEquals, surely assertEqual can be a template with variants for different data types? Type specification in methods names should not be needed as far as the user experience is concerned.

It would be nice if the example using Threads could be complemented with something a bit more high level. Explicit thread management should be seen as the tool of infrastructure not of application. So D programmers should be drawn more to using spawn, or the parallelism module for their concurrency and parallelism. Go has done the programming world favours here by locking threads opaquely inside the runtime system.

C++ has asynchronous function call and futures, and there are actors, dataflow and CSP libraries out there that should wean C++ programmers off manually working with threads. Java is going the same route with explicit use of threads being seen as a mark of 1990s thinking rather than 2010s thinking.

I also note that Python has chosen to eschew assertEquals in favour of assertEqual, even though TestNG (and JUnit4) has not — but then Java testing is being revolutionized by Spock.

xUnit style testing frameworks will soon be ancient history on the JVM (though like COBOL is won't go away). xUnit style testing frameworks are already ancient history in C++, cf. Catch from Phil Nash, and indeed CUTE from Peter Somerlad, though the latter is is not as favoured as the former.

So I am just wondering if dUnit, following TestNG (and JUnit4, which just copied TestNG initially, but then started adding third rate suport for data driven testing) is the right label for this. Test frameworks should be in harmony with the language. xUnit is a system for Smalltalk that got bolted onto Java and then evolved not entirely well. TestNG is good especially where you need to create dynamic smoke tests from the full set, and especially for doing data-driven testing. Spock also has great support for data-driven testing.

Final point for now is the relationship between D built-in unit testing and a bigger test framework, which should handle integration and system testing as well as unit testing.

Put all these points together and I suggest that dUnit is wholly the wrong name for this test framework. Give it another to remove the association with sUnit and TestNG to allow is to become more in harmony with D and, more important, to allow it to focus on integration and system test and not be bound to unit test.

I don't have D codes that need more that the built-in unit test capability but I am already pushing the limits, so will be happy to try this module out, but sadly month…

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 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

On Thursday, 13 June 2013 at 00:10:56 UTC, bearophile wrote:
> In that code have you felt the lack for some built-in feature for D (Like some introspection, some hooks, some dynamic feature, etc)?

D(1)Unit has a 'fixturebuilder' that iterates over 'ModuleInfo' and 'localClasses', and finally follows 'base' links to discover the test classes that have to be derived from 'TestFixture'.

For d(2)unit, Juan Manuel Cabo didn't use all this introspection. With the 'mixin', the single inheritance must no longer be spent for the testing framework. '__traits(allMembers' and '__traits(compiles' are good enough support for the compile-time discovery of the tests.

User-Defined Attributes were great to get rid of the required naming of the member functions. But here I would wish for more. As far as I understand:

1. I cannot have both '@Ignore' and '@Ignore("some reason")'
2. I cannot have the 'mixin' implied by attaching '@UnitTest' to a test class

> Maybe you can replace code like this:
>
> final switch (color)
>             {
>                 case Color.red:
>
>
> With code like:
>
> final switch (color) with (Color)
>             {
>                 case red:

Done. Shame on me: AnalyzeD has the style warning "prefer with for switch statements".
(What's the source of this guideline?)

I dislike this guideline when used together with "put braces around all statements, even single statements". Either you need an exception to the rule or you have to write less attractive code with 'switch' and 'with' on separate lines with an extra indentation level.

On Thursday, 13 June 2013 at 00:00:05 UTC, Juan Manuel Cabo wrote:
> I'm glad that dunit was of use to you and that the fork
> went well.
> I'm sorry I couldn't follow up on it.
>
> --jm

We are much obliged for you providing the foundation.

Your announcement and SiegeLord's port of Tango were the starting signal for our company to go forward from D1/Tango/DUnit to D2/Phobos/Tango(log and xml)/dunit.

1. assertEquals vs. assertArrayEquals

Currently, the reporting of failures is the main reason for having two functions.
For short arrays of short items, the difference looks best using 'assertEquals'.
With 'assertArrayEquals', you'll only get the index and the first mismatch reported.

For multi-line representations, I would wish for something like Python's difflib.ndiff in D.

2. assertEventually

I fear, 'assertEventually' was born out of the old-style threading where you poll shared memory for the result of an asynchronous computation. (In our company, we avoid testing asynchronous code in unit tests as much as possible.)

3. ancient history

I would rather call xUnit a proven tool. (As the inventors of 'Spock' do.)

Still, programmers "in the trenches" often think, that automated testing is a waste of time. Do you think, this is due to a flaw in xUnit testing? I was still optimistic that in a few years I no longer have to explain how to mock objects to test interactions. On the other hand, I've yet to see a keyword-driven test for complicated features.

4. "required reading"

I'll try and 'Catch' up with 'CUTE' 'Spock'.

My favorite was 'Cucumber'. (In our company, we currently use Python's 'unittest'  for integration testing, although we stick to the xUnit framework.)

5. wrong name 'dunit'

I could get to like 'detest'. It would match up with 'deject' :-)