xUnit Testing Framework for D

[Russel Winder]

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 at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20130613/b8e3c27a/attachment.pgp>