digitalmars.D.bugs - [Issue 1952] New: Support a unit test handler
- d-bugmail puremagic.com (24/24) Mar 26 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1952
- Janice Caron (2/4) Mar 27 2008 Why?
- Lars Ivar Igesund (5/10) Mar 27 2008 Tango already has support for a such a handler, but it would be nice if ...
- d-bugmail puremagic.com (11/12) Mar 27 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1952
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
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
Janice Caron wrote:On 27/03/2008, d-bugmail puremagic.com <d-bugmail puremagic.com> wrote: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 IgesundI'd like to see a way for the D language to push unit test handling into an external library.Why?
Mar 27 2008
http://d.puremagic.com/issues/show_bug.cgi?id=1952 jason.james.house gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aaroncraelius gmail.comWhy?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