Unit Tests with Team Developer: TDUnit


Like many developers who are working with the Team Developer from Unify (Gupta / Centura), our company has the task to raise the existing TD application to the version 5.x or 6.x of the development environment. Central issue for us is „unicode“, because we had written quite a few external C libraries which perform string processing. They had been written 10 years ago because of performance issues. So we face the choice to make the C libraries either unicode-compatible or refactor them within the team developer. We have decided for the second option. Problem: How can we ensure, that over 100 newly written functions do the same as their predecessors?

Unit tests

A look outside the box shows that other programming languages (Java, .NET) use quality assurance techniques. There, at least in large projects, it is customary to write so-called unit tests in addition to the actual program code. During my investigations, mainly two sources were very helpful to me: The book The Art of Unit Testing: With Examples in .Net by Roy Osherove, as well as the unit testing framework NUnit for Visual Studio.

Definition of Unit Tests

A very condensed and personal definition of the unit test method:

What is unit testing?

  • Unit Tests are one of several components of the software quality assurance.
  • Unit Tests check individual, isolated functions of the production code.
  • Unit Tests can run at any time. Now and in the distant future.
  • Unit tests can be run automatically.
  • Unit tests are fast.
What is a unit test framework?
  • It helps programmers as much as possible in the writing and running of unit test functions.
Why should you write unit tests?
  • To ensure that a particular function does what it should do now.
  • To ensure that a particular function is still doing what it should do  in future.
  • In order to save time in the maintenance of complex software.

Unit testing framework

In general you can write unit tests without a supporting framework – nearly every TD developer has done that already in some cases. But the acceptance to cover all productive functions with unit tests without a supporting framework tends zero in a developer team. So we need a unit testing framework for the Team Developer. Unfortunately, despite intensive research, I could not find a single unit testing framework for the TD. I had to create one myself.
The aim was to support our development team as well as possible in writing unit tests. The well matured project „NUnit“ for visual studio was the blueprint.
In detail, the following requirements are met with TDUnit:
  • The developer needs to create only the test function.
  • He must not even call the test function somewhere. TDUnit recognizes test functions on its own.
  • A set of ready-made assert functions simplifys the writing of understandable tests. One-liners are possible in many cases.
  • Logging is done automatically.
  • If one adheres simple, meaningful naming conventions, one may omit in most cases a self-written logging-message.
  • Debugging of the testing- and productioncode in single step mode is easily possible.
First practice tests show a good acceptance in the development team.


These are the steps you have to perform in order to use TDUnit

  • First you need an .apt-,. app-or .apl file containing production code. The file must compile. Let’s call it Sample.app. In my example, the function under test is an internal function. (Currently TDUnit covers internal functions, functional classes and external functions. Functions within form windows and dialogs are currently still not testable (easily)).
  • Next, an empty SampleTest.app file should be created. Two libraries have to be included: the testing framework TDUnit.apl and the production file under test, in this case Sample.app.
  • Then, you must create a functional class in the test file. Three conventions have to be adhered: 1) The class must be derived from _UnitTestBase. 2) The name of that class must end with „Tests“ – e.g. InternalFunctionsTests. 3) The member function GetContext() must be overwritten with exacty this one line of code: Return SalContextCurrent()
  • The actual tests are written as member functions within the just created class. Each test function must contain an AssertXXX function. Convention applying to the naming of the test function: „Name of the function you want to test“ _ „Description of the test of“_“expected behavior“ – e.g. Calculator_EmptyString_Zero.
  • Running the test from the menu debug/go or press F7. The Testrunner window will appear and all existing tests are performed automatically. If the assert function confirmed the expected behavior it will appear in green color otherwise red.
The result looks like this:


TDUnit is written with the Team Developer 3.1. The zip file contains the framework (TDUnit.apl), as well as a SampleApp with tests. Also a more detailed PDF documentation (in german).
I’d like to read your feedback.

Über thomasuttendorfer
Ich bin Entwicklungsleiter bei der Softwarefirma [ frevel & fey ] in München. Wir entwickeln Business-Software für Verlage und verwenden dafür den Gupta Team-Developer sowie Visual Studio.

14 Responses to Unit Tests with Team Developer: TDUnit

  1. Diego says:

    Hallo ich würde Über thomasuttendorfer von Test-Anwendungen wie, mehr Arbeit, die Firma, die das Team Developer 2.1 verwendet wird, frage ich mich, wenn Sie bieten würde mir die Apps in vesão Text (.apt)


    • Hi Diego,
      here are the files in .apt-format:
      Good luck

      • Diego says:

        Hi Tom, I’m trying to convert your class to tdunit.apt team developer 2.1, because the company I work due to the large number of customizations to the software error has occurred and we are really trying to find a way to minimizalos and I encountered a problem and maybe you can help me in this class you import the file cdk.apl, the developer team there is only 2.1 cdkfwrk.apl which does not contain the functions cqoClass.EnumBaseClasses, cqoClass.EnumClassObjects, cqoClass.EnumFunctions you know of any way that I can get around this.

        thanks for the help

      • Hi Diego, I only have TD3.1 and TD1.1 – no TD2.0. What you can try: I give you a cdk.apl from version TD3.1 here : http://sdrv.ms/OazVFi
        You should be able to open it with your TD2.0 (I saved it in text-format and changed the version number with a texteditor). You then have search ind cdk.apl for cdk31.dll. Change it to cdk21.dll or similar (look in your centura-folder for the exakt name). I see a good chance that this works. Good luck

  2. Diego says:

    olá Tom
    Muito obrigado pelos arquivos, a propósito belo post irá me ajudar muito na empresa que trabalho, começei a acompanhar seu blog e tem bastante coisas interesantes, parabens pelos posts


    • Diego says:

      hello Tom
      Thank you for the files, by the way nice post will help me a lot in the company I work, I started to follow your blog and have enough things interesting, congratulations for posts


  3. Diego says:

    Hi Thomas, I did what you told me and it worked, thank you very much, this will help me a lot here at the company where I am in Brazil, if you want to share the version 2.1, http://goo.gl/4MbHA

  4. Betul Ozmen says:

    Thank you Thomas, for this framework, TDUnit. I’ve just dowloaded and evaluated. I was searching for a unit test tool for Gupta and met your blog. I’m new to unit tests. The concept is clear. I hope I can go on with it. .

  5. Anonymous says:

    Hi Thomas, thank you for this framework. We are using your framework for functional class testing. Is this framework now work with the window level functions? Our application has over 400 window forms covering thousand more window level functions, we are trying to get some way to unit test those function.

    • Yes that’s easy.
      Just create your window to test on the fly and call it’s functions.
      Destroy the window after each test.
      It’s best to overwrite the SetUp() and TearDown()-functions for creation and remove of your window.
      For modal dialogs it’s a little bit more difficult since you can’t create them with SalCreateWindow().
      But you can create a form window as a Container and place your dialog under test on it with SalCreateWindowEx(..).
      I’ve made a simple demonstration which you can download here: UnitTest_WindowFunctions.zip
      If you have any other questions or issues with TdUnit just let me know.
      Regards Thomas

  6. Johnk711 says:

    Excellent post. I was checking continuously this blog and I’m impressed! Extremely useful information specially the last part ddbecgdekbbe

  7. Johng56 says:

    I like the helpful information you provide in your articles. Ill bookmark your weblog and check again here regularly. I’m quite certain I will learn plenty of new stuff right here! Good luck for the next! ecfdkbbdgfee

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:


Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )


Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )


Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: