<< Blog comment attacks blocked by ASP.NET's ValidateRequest feature | Google's Picasa could use Riya's facial recognition >>

Are you using DUnit to test your Delphi applications?

December 26 2006 7:58AM

If you've been reading my blog over the past few months you'll know that I've written a number of posts related to automated testing. We have our own internal test automation framework so I've never really taken a close look at DUnit although having browsed around the SourceForge page for DUnit I'm wondering if the project is still alive/active? This post mentions an update for D2006 back in August stating that a "release version will follow in a few weeks" although the SourceForge pages for DUnit seem very quiet and the bug tracker doesn't have any recent issues logged against the core. Not to mention that it's obviously been more than a few weeks since August 1st, which has me wondering what the state of DUnit really is?

Our internal testing framework has a class called TTestManager, written prior to Delphi 1.0, which manages test execution and handles the "accounting" details like how many tests have executed/passed/failed. One of the design goals was to use as small a footprint of the Delphi RTL as possible to give it the best chance to compile and run in the midst of a changing compiler and RTL. Over the years TTestManager has lived up to this goal and served its purpose well though, I think it's a bit long in the tooth and it may well be time to use something like DUnit. There are a few developers here who have experience using it and I need to sit down with them and get their opinions. One of the biggest problems we have with our tools relates to reporting and the ability to publish test results to the entire team. Again, over the years there have been a multitude of solutions though none of which have been overly effective.

So, this leaves me with the following questions:

Is the DUnit project still alive?
What is your impression of DUnit?
What, if any, changes they would make to it?
Are you comfortable writing tests with DUnit?
How do you publish the results of your testing efforts?

FWIW, in January I plan on spending a little time investigating DUnit to see it's something we should look more closely at.

1e7c0574-2751-4622-aab7-96a79bf3ccc6|0|.0

Tags: Automation

Permalink | Comments (20)

Why does Delphi 2005 IDE require the .NET framework?Now that Delphi 2005 is out and people are beginning to use it I've seen a number of posts on the Bo...Automated testing of ASP.NET web applications using SeleniumDiscussion of how to create Selenium tests for automating ASP.NET applicationsHTTP Load Testing with AutomatedQA's TestComplete 6 and Remote AgentBasic example of HTTP Load Test in TestComplete using the remote agent

Comments

12/26/2006 11:49:12 AM #

Ask these on the mailing lists of the project and see if the community is alive. Is, IMHO, the best way to get a answer to your doubt.

Fabricio

12/26/2006 4:28:47 PM #

My impression of DUnit.

I use it in most of our projects. For instance: to check the tab order in all dialogs, check if calculations are correct, etc. I think it needs more documentations and some polishing. It is great to text non-visual components, like data structures, but to test a GUI app generates too much work.

I use DUnit with Want (same author) for building releases. Prior to generate a package in a Want script I run DUnit tests.

Feel free to ask me more questions.

Eduardo Mauro

12/26/2006 4:42:08 PM #

Fabrico,
Is the mailing list the only place to find activity? How would people know to join the mailing list to find out what's going on??

Eduardo,
Thanks for the info, I'll take a look at Want.

-Steve

Steve Trefethen

12/26/2006 5:06:51 PM #

Steve,

We using DUnit here and really like it.

The main contributors have been busy with other projects for the past 6 months, but, they still will pop in and answer questions etc. One of the contributors works here at my company. I will let him know about this blog entry when he gets back from Christmas break.

The mailing list is where the activity happens, but as I said its been a while since the major players were active on the list. I can't remember the particulars about the update that you talked about but, we are using it with Delphi 2006 and it seems to work pretty nicely.

There was a flurry of posts, ok flurry may be too strong, recently about an extension that someone is doing to integrate the running of DUnit right into the BDS's IDE. It looks interesting.

Hope that helps

-Ray

Ray Jenkins

12/26/2006 11:29:26 PM #

Hi Ray,
Thanks for the comment. I'm suprised to hear that the "action" happens on the mailing list since it hides the activity from any onlooker. I'll continue to explore the world of DUnit over the next few weeks and see where it leads.

-Steve

Steve Trefethen

12/27/2006 3:56:22 AM #

I'm using it quite a bit. It's crucial to my development.

I was worried that support had dropped off and am glad to hear that the mailing list is at least a little bit active.

Bruce McGee

12/27/2006 7:15:16 AM #

We use an abstracted test class so that unit tests can be run in any testing framework (and so tests can be registered from packages)... For instance, we have a TestComplete class that dumps all the output to the TestComplete log. Since my other developers don't have TestComplete, we also have a generic class that can just output to the screen. All tests are registered in the initialization sections and the units are conditionally compiled in... The test classes run all registered tests. So far, I've not really seen the benefit of DUnit over what I have. It is cool (used it in a small project), but I really have all that I need with the above solution for now and I like to have the tests compiled into the debug version of my app to test converage/allocations/etc...

Ryan McGinty

12/27/2006 8:35:32 AM #

We use it in the daily build for some library code.
It hasn't become a part of the development process though.
Especially the .dtl test dll way of working is great.
Ide integration could be better at times.
Also it is pretty hard to setup so that it does stress testing and checks for corruption and leaks too.

Bart

12/27/2006 4:13:23 PM #

I started to write a reply here, but it got fairly long and I needed to use some HTML, so I turned it into a blog post instead:

blogs.teamb.com/.../DUnit.aspx

Thanks for asking!

Craig Stuntz

12/27/2006 6:35:08 PM #

Craig,
Excellent post! Thanks for the feedback this is exactly the kind of thing I was looking for. I'd really like to collect more feedback like this to see what kind of testing facilities people are interested in.

FYI, I first tried posting this over on your blog but got the "Object reference..." error.

-Steve

Steve Trefethen

12/28/2006 3:24:46 PM #

Yes, commenting on the TeamB blog server isn't working at all now, and hasn't for the last couple of weeks. The appropriate folks are aware of the problem.

Craig Stuntz

12/30/2006 4:31:57 PM #

I am quite satisfied with DUnit.

I have inherited a largish code base to maintain and work on. Adding unit test is a great way to really get to know the code and make the improvements. The tests are also used to test if the code works for VCL.NET. Simply add {$IFDEF CLR} [Test] {$ENDIF} to the test functions and add the test units to a VCL.Net project.

The test case generation bits could be improved:
- the .ctor method is shown.
- Make it possible to add tests for properties.
- Make it possible to add for methods which are not part of a class.
- I would like it is {$IFDEF CLR} [Test] {$ENDIF} was added before the testmethods.

The result of the unittest are still handeled manually, in future TestComplete will be used to handle the results.

I have one problem with DUnit, and that is that it is difficult to define and test only a subset.

Ronald

Ronald Hordijk

1/2/2007 5:48:08 PM #

DUnit is alive and well. I definitely use it every day (I'm a "minor developer" for DUnit).

DUnit "suffers from a high level of maturity" which means the code base hasn't changed much and the few remaining issues are too boring to fix

The bug tracker was moved off of SourceForge many moons ago to http://suigeneris.org/issues/browse/DUNIT - most of the bugs there are the bugs "imported" from the SourceForge page.

In general DUnit's most active location is the mailing list.

Jon Bertrand

1/2/2007 6:05:29 PM #

I'll spam a reply to Craig Stuntz' issues with DUnit here since his blog isn't working.

A few DUnit tips:

1)  To run just one test from DUnit:

Click on that test (so it's highlighted in the test tree) and click the "second/smaller" green arrow.  As I recall one of the Function keys is a short cut for it (like F8 or F9) but I don't recall which one.

2)  Deselect parts of the tree:

First - get yourself a good tree structure by using the "dot notation" when you name your test suites.  Best learned by example:

  RegisterTests('CommonFiles.xStrings.TParser', TParser.Suite);
  RegisterTests('CommonFiles.xStrings.TObject2', TObject2.Suite);
  RegisterTests('CommonFiles.xFiles.TObject3', TObject3.Suite);

Gives a nice tree like:

-CommonFiles
--xStrings
---TParser
----Test_Method1
----Test_Method2
---TObject2
----Test_Method1
--xFiles
---TObject3
----Test_Method1
----Test_Method2

Then click in the list view on any of the items (for example click on the xStrings item) and click the "clear check box" button and it will clear all the checks in that suite.

Maybe you sould add:

Needs a little better documentation to the list

Jon Bertrand

1/6/2007 5:01:13 PM #

Steve and everyone else,

Apologies for not answering sooner, I've been rather wrapped up in a major CodeHealer update that is coming soon.

Anyway, DUnit is definitely alive and being improved, and I have just notified the SourceForge DUnit developer list of a 9.3 update that is ready for release, and contains some significant improvements.

As soon as I have approval from the rest of them I will release it through the normal channels at SourceForge, and will let you know here as well, and that will hopefully be in the next week or so.

Once 9.3 is released I have some other pending additions to look at, so stay tuned and keep the contributions coming!

Sign up on the dunit-interest list at SF for more news.

All the best,

Jud

Jud Cole

1/7/2007 8:45:29 PM #

Hi Jud,
Thanks for all the great info. I'm glad to see things are alive and well! I haven't had a chance to dig into DUnit yet though I hope to spent some time in the next month or so.

My only feedback at this point would be to try and expose at least some of what's going on in the mailing list on a website somewhere so that the public can easily tell that things are alive and well.

-Steve

Steve Trefethen

1/26/2007 3:06:34 PM #

Hi Steve,

as noted by other DUnit folks, I think DUnit's core testing framework has reached a given maturity that hasn't been prodded much because the Delphi/Win32 compiler that it is primarily targetting, hasn't moved too much in the past 5 years either. The fact that lists are silent is probably due to the fact that users are satistifed with the system, or have grown accustomed to its idiosyncracies. My main DUnit notes/comments follow:

1) I found it a pity that the DUnit wizard Borland presented with D2006 was buggy (e.g. it mishandles an elementary keyword such as 'constructor'). I think this put off many potential new users of DUnit, which now finally had it at their fingertips "out of the box".
2) Instead of delivering pre-compiled binaries for the DUnit framework, which cannot be replaced with anything you can download from SourceForge, you should provide easily versionable/upgradeable source files and a nice standard UI switch to link the framework source into the current project. It's such a shame that, only shortly after BDS2006 shipped, a significant update was released on SourceForge and there was no notification in BDN or e.g. on the Welcome Page, where zillions of BDS users could have seen it and upgraded.
3) An interesting IDE integration exercise is now happening which allows to view DUnit-related test result messages etc. in the BDS Events window, skipping straight to failing test method code in the editor, etc.
4) What I'd also like to see is some kind of tag notation that allows to establish a one-to-one (or many-to-one) relationship between test code and tested code (method).

Relating to your latest comment to Jud, the mailing list archives can be browsed elsewhere on the SourceForge website. So it's perfectly possible for people to access this on the web.

Kristofer Skaug

2/6/2007 1:18:07 PM #

Hi Steve,

We are using DUnit from D7 and BDS2006. It is very useful, we even tried some extensions to integrate Specification pattern.

For now I think the most annoying is the BDS 2006 integration. E.g. I liked very much the DUnit/TestClass menu option from the old EPC DUnit Wizard (http://www.xpro.com.au/Freeware/DUnitWizard.htm). It allows you to add test classes on a given unit at any time, via the Clipboard.

In BDS 2006, if tests are already written for a class, it is difficult to add a new class in the same unit and have the test class created for it.

I also wonder how would someone test nested classes...

Marius Popescu

2/14/2007 3:52:34 AM #

To everyone listening / watching,

Thanks for the extra comments, we'll see what we can do between Steve, the rest of CodeGear and ourselves (and any other volunteers) to improve things further with those suggestions.

I've finally had enough time to wrap up a DUnit release, so I am pleased to notify you all that DUnit 9.3.0 is now available for download at SourceForge.

http://sourceforge.net/projects/dunit/

It's been a long time coming, but I think that you will be pleased with the result!

A big thank you goes out to Peter McNab for most of the work that is included in this update - excellent job Peter!

From the 9.3 README:

Recent additions to DUnit 9.3.x
-------------------------------

FASTMM support, including optional memory leak checking on a per test basis, resulting in improved execution speed of many tests.
New DUnitW32 project group for Delphi 2005+ with new projects DUnitW32,
DUnitTestLibW32 and UnitTestsW32.
New DUnit4Net project group for Delphi 8+ with existing project UnitTests4Net.
Automatic MadExcept support for stack tracing in TestFramework.pas.
Optional checking that each test case calls at least one CheckXXX method.
Optional detection of each test case that overrides the global GUI test case settings.
Optional halting of a repeated test on the first failure.
Carried the GUITestRunner.pas changes to the main form creation over to NGUITestRunner.pas and QGUITestRunner.pas.
Added a display refresh timer to GUITestRunner to ensure display update in long unit tests.
A couple of minor bug fixes.

All the best,

Jud Cole
DUnit Project Admin
SOCK Software
Makers of CodeHealer for Delphi and SOCKShell