How can I disable DUnit tests programmatically?

For integration tests of Habari ActiveMQ Client libraries, I created a DUnit test suite which runs once for every version of the message broker. Unfortunately, some of the tests always fail because of known bugs in the tested version of the message broker (not the client library).

This means the test suites will never complete with 100%. For automated tests however, I need a 100% success score, otherwise, continous integration tools will detect a failed build.

DUnit does not offer a ready-made method to disable tests in a test suite by name. So I wrote a procedure which takes a test suite and a list of test names, and then disables all tests with a matching name, and also performs a recursion into nested test suites.

Here is the code, feel free to use it:

procedure DisableTests(const ATest: ITest; const AExclude: TStrings);
var
  I: Integer;
begin
  if AExclude.IndexOf(ATest.Name) <> -1  then
  begin
    ATest.Enabled := False;
  end;
  for I := 0 to ATest.Tests.Count - 1 do
  begin
    DisableTests(ATest.Tests[I] as ITest, AExclude);
  end
end;

Example usage (the TStringlist ‘Excludes’ is created in the Setup method):

procedure TActiveMQ541Suite.SetUp;
begin
  // fill test suite
  inherited;

  // exclude some tests
  Excludes.Add('TestBytesMessages');
  Excludes.Add('TestBigMessages');
  DisableTests(Self, Excludes);

  LaunchActiveMQ('5.4.1');
end;

NetBeans IDE 7.0 Beta Now Available!

The NetBeans team is pleased to announce the availability of NetBeans IDE 7.0 Beta.

NetBeans IDE 7.0 Beta introduces language support for development to the Java SE 7 specification with the JDK 7 platform. The release also provides enhanced integration with the Oracle WebLogic server, as well as support for Oracle Database and GlassFish 3.1.

Additional highlights include Maven 3 and HTML5 editing support; a new GridBagLayout designer for improved Swing GUI development; enhanced support for executing and debugging standalone Java EE applications; and enhancements to the Java editor.

Release Highlights

Continue reading

Thread Synchronization with Guarded Blocks in Delphi

The Embarcadero DocWiki for Delphi recommends that “thread synchronization techniques should be based on SyncObjs.TEvent and SyncObjs.TMutex.

There is, however, another synchronization class available since Delphi 2009: TMonitor. It uses the object lock which has been introduced in this version and which caused the size of TObject to increase by four bytes (for details read “Why Has the Size of TObject Doubled In Delphi 2009?“, which finds that “The ability to lock any object is a good feature to have, especially in a multi-CPU, multi-core world.”).

Using TMonitor.Wait, the synchronized code waits until a lock is released without wasting processor time.

This example uses TMonitor.Wait and TMonitor.PulseAll, based on an article about guarded methods in the Java(tm) tutorials:

„This kind of application shares data between two threads: the producer, that creates the data, and the consumer, that does something with it. The two threads communicate using a shared object. Coordination is essential: the consumer thread must not attempt to retrieve the data before the producer thread has delivered it, and the producer thread must not attempt to deliver new data if the consumer hasn’t retrieved the old data.”

In this example, the data is a series of text messages, which are shared through an object of type Drop:

Continue reading