Using Delphi "Unit Aliases" to aid in unit testing

• Resolving unit dependencies.  Think of a case where a unit uses another unit just so it can access one symbol from that unit.  Assume that the used unit iteself uses many other units.  In order to build a test for the code in this unit, the compiler must resolve all used units.  Due the nature of the IDE source code, it’s very easy to get into a situation where a unit test ends up pulling in a very large number of source units that aren’t really needed for the test.
• Resolving IDE services accessed by the unit being tested.  Think of a case where a unit being tested uses a core IDE service to, say, display status in the IDE splash screen during startup, or to output a message to the IDE’s message view (just two of many possible examples).  Because the IDE isn’t running, it’s unlikely that these services would be available to the unit test.

There have been different approaches to overcoming these challenges, that those of us on the IDE team have taken when writing unit tests:

• Refactoring the unit being tested has helped in some of these cases.
• Another approach has been to litter the code being tested with {$IFDEF} or {$IFNDEF} directives so that only the code being tested is visible to the test.  Yes, I use the term "litter" because of its negative connotation –  using IFDEFS can compromise code readability and maintainability.  Also, any time you change code (even if to only add/remove IFDEFS), you risk breaking something (yes, this may be less of an issue, since you are, after all, changing code so you can write unit tests).
• A third approach, which is the subject of this post, is to provide a unit with stubs for the dependencies and then use the Delphi compiler’s Unit Alias feature when building the unit test.  A major benefit of this is that it allows you to test existing code without having to modify that code.

Take the over-simplified unit shown in this screenshot:

Let’s assume we want to write a unit test for TMyClass.DoSomething and that the OutputAMessage procedure 1) lives in a unit (MessageServices.pas) that pulls in a lot of extra units, and 2) requires UI that is not available while unit testing.  A simple way to write this test is to provide a unit which provides an implementation of "OutputAMessage".  Let’s call the unit TestStub:

Yes, you could use an IFDEF in Unit1’s uses clause to conditionally use either the MessageServices or TestStub unit.  But what if the unit being tested is more complex?  What if there are many functions/symbols/etc. living in spearate units that you want to provide a stub for?  What if the code uses a unit name in order to qualify a symbol (i.e. what if the code in Unit1.pas referenced "MessageServices.OutputAMessage" instead of just "OutputAMessage" in order to resolve a symbol ambiguity)?

Unit aliases allow you to address those concerns.  When compiling the unit test, if you define a Unit Alias of "MessageServices=TestStub", it will use the stubbed version in TestStub.pas.  When you build your main project, it will continue to use the real version in MessageServices.pas.  If you wanted to provide a single stub unit for multiple "real" units, you would just provide addtional aliases:  "MessageServices=TestStub;AnotherUnit=TestStub".  And due to the way Unit Aliases are implemented by the compiler, it will properly alias unit names used as scope qualifiers in the code.  As mentioned earlier, a great benefit of this approach is that you can test your existing units without having to modify them at all.

You can define Unit Aliases in the IDE using the Project | Options dialog.  In Delphi 2010, this option is on the "Delphi Compiler" page.  When building from the command line, the appropriate compiler switch is -A (i.e. -AMessageServices=TestStub).

While the compiler’s support for Unit Aliases was originally added to increase backwards compatibility and to ease migration when a new version of a unit has a different name than an older version, I have found the feature to be quite useful in helping to unit-test code that might otherwise not be easily tested.

Share This | Email this page to a friend

Posted by Chris Hesik on November 24th, 2009 under Delphi, IDE, RAD Studio |