www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1952] New: Support a unit test handler

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1952

           Summary: Support a unit test handler
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: jason.james.house gmail.com


I'd like to see a way for the D language to push unit test handling into an
external library.  If a unit test is treated as a delegate, it can then boil
down to a single call to a unit test handler.

I'd suggest using any args of the unit test to be arguments into whatever unit
test handler exists.  This would allow use of special libraries built to
leverage an already existing unit testing framework.

Example:

source:
unittest("My test name"){ ... }

... causes the compiler to call:
void unitTestHandler(delegate void dg(), char[])


-- 
Mar 26 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 27/03/2008, d-bugmail puremagic.com <d-bugmail puremagic.com> wrote:
  I'd like to see a way for the D language to push unit test handling into an
  external library.
Why?
Mar 27 2008
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Janice Caron wrote:

 On 27/03/2008, d-bugmail puremagic.com <d-bugmail puremagic.com> wrote:
  I'd like to see a way for the D language to push unit test handling into
  an external library.
Why?
Tango already has support for a such a handler, but it would be nice if this could be extended further by adding support for named unittests. -- Lars Ivar Igesund
Mar 27 2008
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1952


jason.james.house gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aaroncraelius gmail.com





 Why?
Simple. It allows users of D to make a lot of unit testing design decisions up front avoid code bloat inside unit tests. Should exceptions be caught? Should all tests be run? How do you handle expected failures? How do you report results? Can D be hooked up to continuous integration program X? Etc... --
Mar 27 2008