www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - xUnit Testing Framework for D

reply "Mario Kroeplin" <linkrope github.com> writes:
Here is the 'dunit' mentioned in the talk by Stefan Rohe:
https://github.com/linkrope/dunit

D-stroy ;-)
Jun 12 2013
next sibling parent reply Juan Manuel Cabo <juanmanuel.cabo gmail.com> writes:
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
Jun 12 2013
parent "Mario Kroeplin" <linkrope github.com> writes:
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.
Jun 16 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Jun 12 2013
parent "Mario Kroeplin" <linkrope github.com> writes:
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.
Jun 16 2013
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
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
=20
 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 =E2=80=94 but then Jav=
a
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.=20

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=E2=80=A6

--=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
Jun 13 2013
parent "Mario Kroeplin" <linkrope github.com> writes:
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' :-)
Jun 16 2013