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:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
