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 on TILO visit TILO homepage.
How does it work
What the programmer has to do
All that the programmer has to do is create in each DLL, some functions which 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 which have the prototype:
bool FunctionName (char *pszNotes);
which 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 names 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 has 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. The modules are:
- 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 which 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 etc.
- GUI, a C# Windows Forms executable assembly.
A project means one or more DLLs that are to be tested. Projects are saved to disk in XML format.
Classes per modules
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 has succeeded and 0 (zero) if the test has 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 functionalities. It exposes the following members:
Status: a read-only property that is obtained by aggregating the status of the contained categories and unit tests [which can be NotRun, Running, Succeeded, Failed, Error].
Execute: a method which will call Execute on all subcategories and contained UnitTests.
StatusChanged: an event which 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 by 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, so 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 be loaded.
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 in it:
The Loader class loads and saves projects from and to disk. It uses the Parser class in this process. The Loader class is a singleton which exposes the following members:
void LoadProjectFromDisk (Project prj, string strPath): reads an XML file from disk and creates a structure of modules, categories, 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 which 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 be executed.
Why TILO?
TILO is a God in the African mythology (Tongan tribes of Malawi and Zambia). He is a busybody. Unlike most of the African Gods, TILO likes to be involved. He fusses and gets into furious fits when things aren't to his liking. But he is always there to lend a helping hand. [Source: GodChecker.Com]
In a similar way, 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 a 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 that.
- Share with us any enhancements that you have done to TILO.
This program is distributed with 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 any query about TILO. If there is any defect please let us know.
TILO's faithfull subjects, followers and developers:
- Octavian-Paul ROTARU
- Ion Irinel Diaconu (Gec)
TILO Hompage
