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
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.
TILO’s faithful subjects, followers, and developers:
- Octavian-Paul ROTARU
- Ion Irinel Diaconu (Gec)
TILO Hompage: http://tilo.compdb.net/