DUnit: Xtreme Unit Testing for Delphi

Hi Jarrod,

I'd love to see this move forward, but I ran into serious issues with
the Abbrevia unit tests when I tried to make them compatible with DUnit2.

Abbrevia creates a lot of tests dynamically at startup based on the
presence of test files.  I was able to get everything compiling under
both DUnit and DUnit2 using some (possibly incorrect) stubs and aliases,
but it crashed when I tried to run it.  It looked like it was an issue
with the test runner proxies, but tracking it down was a PITA, so I just
ported DUnit to FreePascal instead (which still hasn't been merged).
The DUnit2 improvements are nice but it sure seemed a lot more complex.

If you're interested in seeing what I was trying to do, everything's in
Subversion at:

  https://tpabbrevia.svn/sourceforge.net/svnroot/tpabbrevia/trunk

I removed the DUnit2 support in revision 488.

I hope it's possible to support both DUnit and DUnit2 in a single
codebase, possibly with some conditional defines.  Delphi has included a
version of DUnit since Delphi 7 or so, and being able to run unit tests
without installing another package is more important to me than any of
the improvements DUnit2 provides.

-- 
Craig Peterson
Scooter Software               http://www.scootersoftware.com/
Abbrevia Project Admin         http://tpabbrevia.sourceforge.net/

Hi Craig, thanks for your reply.

> Abbrevia creates a lot of tests dynamically at startup based on the
> presence of test files.  I was able to get everything compiling under
> both DUnit and DUnit2 using some (possibly incorrect) stubs and aliases,
> but it crashed when I tried to run it.

We do some basic dynamic test creation in one of our test projects.
I'll look at the abbrevia code and see what I can find.

> I hope it's possible to support both DUnit and DUnit2 in a single
> codebase, possibly with some conditional defines.

Most users need only change a single line in the dpr (you no longer
have to free the result of TextTestRunner.RunRegisteredTests making it
behave the same way as the GUITestRunner) and a path change to use the
new source. There are changes to when test case classes are created
and freed, and hence when SetUp and TearDown are called, but for most
users this should not alter the execution of their test code.

Where the changes *are* more complex is when you need to work with the
test framework at a lower level such as create tests dynamically. I
expect this will not effect many users.

Cheers,
Jarrod Hollingworth

Jarrod,

It seems that there are concerns about backwards compatibility. The
apparent lack of interest may be due to people having a good-enough
solution with the current DUnit.

I've been working with Python lately, and the standard library includes a
JUnit-style module that covers the basics of testing. But there are a dozen
or so alternative testing frameworks that are mainstream, and people
serious about testing use one of those.

Perhaps what you should do is to formally fork DUnit (perhaps under a name
different from DUnit2), publicize it, get a user base, and see what
happens. That's how DUnit was born:

http://www.suigeneris.org/writings/1999-11-29.html

-- 

On Wed, May 23, 2012 at 7:41 PM, Jarrod Hollingworth <
jarrod.hollingworth@...> wrote:

> Hi Craig, thanks for your reply.
>
> > Abbrevia creates a lot of tests dynamically at startup based on the
> > presence of test files.  I was able to get everything compiling under
> > both DUnit and DUnit2 using some (possibly incorrect) stubs and aliases,
> > but it crashed when I tried to run it.
>
> We do some basic dynamic test creation in one of our test projects.
> I'll look at the abbrevia code and see what I can find.
>
> > I hope it's possible to support both DUnit and DUnit2 in a single
> > codebase, possibly with some conditional defines.
>
> Most users need only change a single line in the dpr (you no longer
> have to free the result of TextTestRunner.RunRegisteredTests making it
> behave the same way as the GUITestRunner) and a path change to use the
> new source. There are changes to when test case classes are created
> and freed, and hence when SetUp and TearDown are called, but for most
> users this should not alter the execution of their test code.
>
> Where the changes *are* more complex is when you need to work with the
> test framework at a lower level such as create tests dynamically. I
> expect this will not effect many users.
>
> Cheers,
> Jarrod Hollingworth
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Dunit-interest mailing list
> Dunit-interest@...
> https://lists.sourceforge.net/lists/listinfo/dunit-interest
>



-- 
Juancarlo *Añez*

Hallo,

i have downloaded the current version of dunit2 from svn,
here are some quirks i found :
(with D2010)

1)
I can't see where/how this feature is enabled :
On 24.05.2012 01:08, Jarrod Hollingworth wrote:
> - Double-click a failing test in the GUI test runner to jump to the line of
>    source in the Delphi IDE where the test failed.
Do i have to do anything special for this to work ?
I think this alone would be reason enough (for me)  to switch to dunit2.

2)
Also in a Test-project where i tried to exchange dunit with dunit2
i get this compiler-error
in ...
   ETestFailure = class(EAbort)
      constructor Create;                          overload;
      constructor Create(const ErrorMsg :string);  overload; <----------- here
   end;
the error is :
[DCC Error] TestFramework.pas(62): E2266 Only one of a set of overloaded methods can be published

In a "fresh" project it works, so probably some compiler-switch ?
Any Ideas ?

3)
The Gui-Testing enhancements seem interesting, if i can get it to compile then i would really like to test them.

4)
There is no project-file for the tests - would be really helpful.

5)
There is no XE2-Project !



Nenad

Hi Juancarlo,

> It seems that there are concerns about backwards compatibility.

DUnit2 is highly backward compatible with DUnit. There are many
changes to the framework itself but as far as I'm aware the majority
of users would need few, if any, changes to their test projects.

I'm going to conduct an audit of differences between DUnit/DUnit2 and
migrate a couple of projects to DUnit2 to check if there are any
issues that I'm not aware of (starting with Abbrevia). One change that
I'm going to investigate is removing the need to modify the dpr in
older console test projects (the text test runner in DUnit needs to be
freed but not in DUnit2 - for later dunit test projects using the
dunittestrunner unit this change will be automatic but earlier the
convention was to call and free the text test runner directly from the
dpr).

> Perhaps what you should do is to formally fork DUnit (perhaps under a name
> different from DUnit2), publicize it, get a user base, and see what happens.

There are not enough breaking changes in DUnit2 to warrant this
approach going forward. The majority of users will see it as DUnit
v9.3 + some new features and enhancements = DUnit 10.0. DUnit2 started
as a private fork by Peter McNab due to the major changes to the
framework but in hindsight I think it should have been an official
branch and later merge, in a much shorter timeframe.

DUnit2 already has a good user base - it's been used with tiOPF for
many years (and tiOPF has users right around the world).

Regards,
Jarrod Hollingworth

Hello Jarrod,

It seems to me you are in a good position to become the next administrator
and maintainer of DUnit.

Let me know you SF Id and I'll set you up.

--
Juancarlo

On Sun, May 27, 2012 at 9:04 PM, Jarrod Hollingworth <
jarrod.hollingworth@...> wrote:

> Hi Juancarlo,
>
> > It seems that there are concerns about backwards compatibility.
>
> DUnit2 is highly backward compatible with DUnit. There are many
> changes to the framework itself but as far as I'm aware the majority
> of users would need few, if any, changes to their test projects.
>
> I'm going to conduct an audit of differences between DUnit/DUnit2 and
> migrate a couple of projects to DUnit2 to check if there are any
> issues that I'm not aware of (starting with Abbrevia). One change that
> I'm going to investigate is removing the need to modify the dpr in
> older console test projects (the text test runner in DUnit needs to be
> freed but not in DUnit2 - for later dunit test projects using the
> dunittestrunner unit this change will be automatic but earlier the
> convention was to call and free the text test runner directly from the
> dpr).
>
> > Perhaps what you should do is to formally fork DUnit (perhaps under a
> name
> > different from DUnit2), publicize it, get a user base, and see what
> happens.
>
> There are not enough breaking changes in DUnit2 to warrant this
> approach going forward. The majority of users will see it as DUnit
> v9.3 + some new features and enhancements = DUnit 10.0. DUnit2 started
> as a private fork by Peter McNab due to the major changes to the
> framework but in hindsight I think it should have been an official
> branch and later merge, in a much shorter timeframe.
>
> DUnit2 already has a good user base - it's been used with tiOPF for
> many years (and tiOPF has users right around the world).
>
> Regards,
> Jarrod Hollingworth
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Dunit-interest mailing list
> Dunit-interest@...
> https://lists.sourceforge.net/lists/listinfo/dunit-interest
>



-- 
Juancarlo *Añez*