TILO – An Automated Unit-Testing Tool for C & C++

Introduction

TILO is a program/tool designed to help developers create and run unit tests. Unit tests will have to be coded, not written, and will be executed automatically by the tool.

For more information about TILO, visit the TILO Homepage.

How It Works

What the programmer has to do

All the programmer has to do is to create, in each DLL, some functions that will perform the unit testing and return true for success and false for failure. The tool can only be used to test DLLs. The programmer must export, from each DLL, some functions that have the prototype:

bool FunctionName (char *pszNotes);

that will perform the unit testing and return true or false, depending on the outcome. Also, the programmer must export a function called GetUnitTestProcs with the following prototype:

void GetUnitTestProcs (char *pszUnitTestProcs);

What the tool does

The tool loads the DLL using the LoadLibrary function, calls GetUnitTestProcs to get the name of the unit testing functions, and then calls each function returned in the pszUnitTestProcs parameter. If a function returns false, it means the unit test has failed; if it returns true, it means it succeeded.

Design

Language

The tool is written mostly in C#, and a module is written in C++. The C++ module provides an interface between the native Windows DLL and the managed C# code.

Modules

The application is comprised of four modules:

  • InvokeHelper, a DLL written in C++ whose sole purpose is to provide an interface between the native DLLs and the C# managed code
  • TestingBusiness, a C# assembly that contains classes to support the business of the testing process
  • Loader, a C# assembly that deals with the process of loading the projects from disk, saving them, and so forth
  • GUI, a C# Windows Forms executable assembly

A project means one or more DLLs that have to be tested. Projects are saved to disk in XML format.

Classes per module

InvokeHelper classes

The InvokeHelper DLL exports only two functions, with the following signatures:

int CallGetUnitTestNames (char *strDllName, char *strTestNames);
int ExecuteUnitTest (char *strDllName, char *strTestName, char *strMsg);

The CallGetUnitTestNames function simply loads the DLL called strDllName, finds the GetUnitTestNames function in that DLL, and calls it, passing the strTestNames parameter to it. This function should return non-zero to indicate success and zero for failure.

The ExecuteUnitTest function loads the DLL with the given name, finds an exported function called strTestName, calls that function with strMsg as parameter, and returns the value returned by that function, which should be 1 (one) if the test succeeded and 0 (zero) if the test failed. If the function cannot be found or other errors occur, ExecuteUnitTest should return an appropriate error code (error codes start at 100).

TestBusiness classes

This assembly contains four classes:

  • TestObject
  • UnitTest (derived from TestObject)
  • Category (derived from TestObject)
  • Module (derived from TestObject)
  • Project (derived from TestObject)

A TestObject class is the base class for all the other classes in the module and it provides some common functionality. It exposes the following members:

  • Status: a read-only property that is obtained by aggregating the statuses of the contained categories and unit tests, which can be [NotRun, Running, Succeeded, Failed, Error]
  • Execute: a method that will call Execute on all subcategories and contained UnitTests
  • StatusChanged: an event that will fire when the status of a unit test changes

A UnitTest object represents just that, a UnitTest. This class derives from TestObject. The UnitTest class exposes the following members:

  • Name: a read-only string property specifying the name of the test case
  • FunctionName: a read-only string property specifying the name of the function to be called
  • Message: a read-only string property specifying the message returned from the Execute method

A Category object represents a category of test cases. It encapsulates a series of related test cases. It can contain other categories, such that a tree structure can be formed, where categories are nodes and UnitTests are leaves. This class derives from TestObject. The Category class exposes the following members:

  • Name: a read-only property specifying the name of the category
  • SubCategories: an ArrayList of zero or more Category objects, which are subcategories of this category
  • UnitTests: an ArrayList of UnitTest objects which may contain zero or more items

A Module object represents one DLL that needs to be tested. It contains one or more categories of unit tests. This class derives from TestObject. The Module class exposes the following members:

  • Name: a read-write string property specifying the name of the module
  • DllName: a read-write string property specifying the name of the DLL to load
  • Categories: an ArrayList of one or more Category objects

A Project object represents one unit testing project, which typically contains several modules (DLLs to be tested). This class derives from TestObject. The Project class exposes the following members:

  • Name: a read-write string property specifying the name of the project
  • Modules: an ArrayList of one or more project modules
Loader classes

This assembly contains classes that deal with reading/writing to disk and loading projects. The following classes are contained:

  • Loader
  • Parser
  • UT

The Loader class loads and saves projects from and to disk. It uses the Parser class in the process. The Loader class is a singleton that exposes the following members:

  • void LoadProjectFromDisk (Project prj, string strPath): reads an XML file from disk and creates the structure of modules, categories, and unit tests. Throws an exception if errors occur
  • void SaveProjectToDisk (Project prj, string strPath): writes an XML file containing the project structure
  • static Loader Instance: read-only property that provides access to the singleton instance of the class

The Parser class is called by the Loader during the loading stage, to parse the string returned by the CallGetUnitTestNames function. The Parser exposes the following members:

  • Parser constructor: takes in a string parameter
  • UTs: An arrayList of UT structures, obtained by parsing the string taken in during construction

The UT class represents a unit test to be loaded, as it was read from the input string of the Parser. It exposes the following members:

  • Name: read-only string property specifying the name of the unit test
  • Categories: an ArrayList of string specifying the categories of this unit test, from top to bottom
  • FunctionName: a read-only string property specifying the name of the DLL exported function to execute

Why TILO?

TILO is a god from the African mithgology (Tongan tribes of Malawi and Zambia). He is a real busybody. Unlike most of the African gods, TILO likes to be involved. No heavenly ladders and distancing for him. He fusses and gets into furious fits when things aren’t to his liking. But, he is also there to lend a helping hand.

Source: GodChecker.Com

In a similar way to his heavenly counter-part, our TILO always gets involved. Like TILO the God, TILO the Unit-Testing tool implies the embedding of the unit-test cases inside the actual code. Unit-Test Cases are code: driver programs used to test the functionality of your code. TILO is free software. You can redistribute it and/or modify it as you like, with the following limitations:

  • Do not change its name. TILO the God will get angry if you do.
  • Share with us any enhancements that you did to TILO and you believe can help others.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

We’ll be glad to hear that you are using TILO, so please let us know about it.

Feel free to contact us in case you have a query about TILO.

Report a TILO defect.

TILO’s faithful subjects, followers, and developers:


  • Octavian-Paul ROTARU
  • Ion Irinel Diaconu (Gec)

TILO Hompage: http://tilo.compdb.net/

More by Author

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Must Read