Hi Kris,

We were still running CLR tests internally, but we disabled those back when we shipped XE2. I don't expect the framework code it would ever be used again. If it needs to be resurrected in the future it can be extracted from an older version of DUnit as needed.

I was under the impression that the stack track information came from JCL, but to be honest I haven't looked at it too closely.

Mark

On 10/3/2012 10:20 AM, Kris Golko wrote:
Hi Mark,

Delphi.Net is dicontinued, should we remove CLR code or is=
there a chance for it to be reused in WinRT (with some modifications)?

I hoped we will be able to get the stack trace from the StackTrace prope=
rty. Apparently it's not that simple


From: Mark Edington <medington@users.sourceforge.net>
To: Users of the DUnit Xtreme testing framework for Delphi <dunit-interest@lists.sourceforge.net>
Sent: Monday, 1 October 2012, 21:39
Subject: Re: [DUnit-interest] DUnit improvements

Kris,

I'm all for making incremental improvements to the framework, and this certainly seems like something that would be very useful to have. With the current RTTI support, it should even be possible to avoid having to explicitly call RegisterTest for each test class.

This does bring up again the whole DUnit2 discussion, and if it makes sense to embrace invest this older code base or the newer one.

-- Mark
 
On 9/30/2012 12:23 PM, Juancarlo Añez wrote:
Kris,

It makes sense.

As long as there's a Delphi 7 compatible version, most projects will be fine.

-- Juanca

On Sun, Sep 30, 2012 at 3:59 AM, Kris Golko <krzysztofgolko@yahoo.com> wrote:
Hi All,

As Delphi supports attributes now, it would be easy to modify DUnit, so a test procedure is designates as test by applying the [test] attribute (mirroring NUnit). While trying to implement the change I realised that further modifications are needed - you can only find pointer to a procedure if it's published, so the procedure needs to be executed using TRttiMethod.Invoke. I have a prototype working, but I can't help noticing that the code is becoming increasingly cluttered and suboptimal. For example, TMethodEnumerator could be eliminated.

Currently DUnit design reflects limitation of earlier versions of Delphi. As these limitation have been overcome in Delphi 2010, I think the best course of action would branching DUnit to create DUnit for Delphi 2010 and above. It would allow to rationalise the code and open the way to further improvements.

What do you reckon?




------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Dunit-interest mailing list
Dunit-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dunit-interest




--
Juancarlo Añez


------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Dunit-interest mailing list
Dunit-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dunit-interest