VSoft Technologies Blogs


VSoft Technologies Blogs - posts about our products and software development.

Introducing Delphi Mocks

Delphi has had Unit Testing support (in the form of DUnit) for many years, but until now there very little in the way of Automatic Mocking. By contrast the .NET and Java worlds have plenty of mocking frameworks to choose from. 

So what are Automatic Mocks anyway? Simply put, they are mock objects that you don't have to hand code. What's wrong with hand coding mock objects you might ask? Well nothing, really, but consider the following example, where we pass an instance of our hand coded mock object to the object under test. 

type IFoo = interface
function Bar(param : integer) : string;
procedure TTestSomething.SimpleTest;
something : ISomething;
mockFoo : IFoo;
something := TSomething.Create;
mockFoo := TMockFoo.Create;

 What does our mockFoo mock object actually do, what is it's behavior, how many times will Bar be called and what will it return? It's not obvious from looking at the above code, so you would have to go off and find the TMockFoo

implementation. Not so hard, but what happens when someone else comes along and adds a new unit test that also uses TMockFoo, what happens if they change the TMockFoo implementation, will that break your existing tests. This is where automatic
mocks can help, because you define the behavior and expectations on you mock object right there in the unit test method :

procedure TTestSomething.SimpleTest;
something : ISomething;
mockFoo : TMock
something := TSomething.Create;
//create our auto mock
mockFoo := TMock.Create;
//define the behavior of IFoo.Bar
mockFoo.Setup.WillReturn('hello something').When.Bar(1);
//define our expectations of how  many times TSomething will call IFoo.Bar
//now lets test ISomething.UseFoo
//Now verify that ISomething used IFoo correctly

The auto mock object is defined right there in our unit test, and the behavior is not going to change unless we change it in our unit test. This sort of mocking makes it simple to focus our testing effort on TSomething rather than TFoo (our real IFoo implementation) or TMockFoo.

One of the reasons auto mocking hasn't really happened for Delphi is the lack of detailed and easy to use runtime type information (Rtti) and the lack of runtime code generation (yes it's always been possible, but not through a well defined interface like Reflection.Emit in .NET). Auto mocking involves creating types on the fly, in the case of interfaces, creating a type and implementing an interface. That's not an easy thing to do. There are some examples of this in Delphi's SOAP code, but they are not easy to follow. Delphi XE2 introduces some new features in the RTTI that make creating interface proxies simple. TVirtualInterface creates an implementation of an interface at runtime and marshals the method calls to the OnInvoke method. 

Delphi-Mocks - https://github.com/VSoftTechnologies/Delphi-Mocks is an attempt to create an Auto Mocking framework for Delphi. It makes use of Generics and Fluent style interfaces. Currently only interfaces can be mocked, and it supports only Delphi XE2 at this time. I hope to add support for TObject mocks and earlier versions (D2009+).

EC2 Support in FinalBuilder 7.0

FinalBuilder adds support for Amazon's EC2 Cloud Services. The EC2 Actions allow you to interact with EC2 instances during your build process. This enables deploying to test or production environments running on EC2 services.

The EC2 support add's 16 new Actions to FinalBuilder :

EC2 Get Instance Properties - This action allows you to retrieve the selected property of instances available to you. You can filter which results to return using the optional filters.

EC2 Change Instance States - This action enables you to change the state of one or more instances.

EC2 Run Instances - This action enables you to run (create) one or more instances.

EC2 Terminate Instance - This action enables you to terminate one or more instances. Note that this action is permanent and cannot be undone.

EC2 Get Image Properties - This action allows you to retrieve the selected property of images available to you. You can filter which results to return using the optional filters.

EC2 Create Image - This action enables you to create an image from an instance.

EC2 Deregister Image - This action enables you to deregister (delete) an image. Please note that this action is permanent and cannot be undone.

EC2 Create Volume - This action enables you to create a volume, either as a blank volume of a specific size, or a volume restored from a snapshot.

EC2 Delete Volume - This action enables you to delete a volume. Note that this action is permanent and cannot be undone.

EC2 Attach Volume - This action enables you to attach a volume to an instance.

EC2 Detatch Volume - This action enables you to detach a volume from any instances it is attached to.

EC2 Get Volume Properties - This action allows you to retrieve the selected property of volumes available to you. You can filter which results to return using the optional filters.

EC2 Get Snapshot Properties - This action allows you to retrieve the selected property of snapshots available to you. You can filter which results to return using the optional filters.

EC2 Create Snapshot - The Access Key and Secret Key for your AWS account. If "Use Global Values" is checked, the values set in the options page (Tools > Options > Internet > EC2) will be used instead.

EC2 Delete Snapshot - This action enables you to delete a snaphot. Note that this action is permanent and cannot be undone.

EC2 Get Availability Zones - This action allows you to retrieve the name of availability zones available to you. You can filter which results to return using the optional filters.


FinalBuilder: now with NuGet-y goodness

NuGet is a open source package management tool for .NET applications. It allows you to very simply install, create and share reusable assemblies. With the latest release, FinalBuilder now contains a set of actions to help you interact with NuGet as part of your automated build process.


First things first

To get started, you'll need to download nuget.exe from codeplex. Optionally, if you'd like to Push or Delete to nuget.org you will need an APIKey. You can get one by creating an account at nuget.org and going to the My Account page.

Once you have those, in FinalBuilder go to Tools -> Options and under .Net Tools select NuGet. Set the path to the folder where nuget.exe is located and if you have an API Key, add it in as well.


Installing packages

If you use nHibernate, jQuery or any of the 1500 other packages that are available from nuget.org, you can use the NuGet Install action to keep your build process up to date. This is particularly useful if you're using FinalBuilder on a continious integration server such as FinalBuilder Server.

You can install from the default (nuget.org) server or your own custom package feed. Having your CI server pull down the latest version of a third party library is a quick and easy way to see if the latest version has any breaking changes for your codebase. If it does, you can choose to install a specific version until you've modified your code to be compatable with the changes.


Sharing packages

If you develop an open source library for .NET and want people to use it, it makes a lot of sense to have it published on NuGet. And if you use FinalBuilder to build the library, it's pretty simple to add publishing into your build process. Or, if you have a lot of shared internal assemblies and are looking for a better way to distribute them, publishing to an internal NuGet server may make your life a lot easier.

FinalBuilder has 4 actions to help with the publishing process. If you're familiar with using nuget.exe from the command line they should be very familiar.

The Spec action creates a .nuspec file - either with placeholder data or with metadata from a project file (.csproj) or an assembly. The nuspec is an XML file, so after you've created it you can use FinalBuilder's XML actions to easily manipulate it.

The Pack action creates a .nupgk file from your nuspec, ready for deployment. Alternatively, you can create a package directly from a project file. The Pack action lets you choose which project configuration to use (if you're using a csproj), override the version number and use a pattern to exclude files from the package.

Once you have your nupkg, you can use the Push action to publish it to either the default server on nuget.org, or to your custom NuGet server. If you prefer, you can upload but not publish the package. That way you can manually go to the site and press the Go button before anyone will see it.

Lastly there's the Delete action, which removes the package you specify from the server.


Further information

NuGet.org is the place to go any lots more information. Scott Hanselman also has an excellent presentation that covers everything you should need to know (although we disagree with his choice of build automation tools :) )

Over the next few posts, I'm going to try to talk about some of the lesser known features in FinalBuilder, and show some ideas and techniques that I hope will help you improve your FinalBuilder projects.

Wouldn't it be great if a failed action could automatically retry if it fails?

Absolutely, it's a great idea, and its a feature that's been in FinalBuilder for several years. Unfortunately it's not as obvious as it could be, we ran out of screen real estate a few versions back and it got pushed into another dialog (rather than add another tab!)

Note that this feature should really only be used when accessing a resource which might occasionally fail, for example we use this on our SignTool action when codesigning/timestamping the exe's because the timestamp server (Verisign's) sometimes fails to respond. We found if we ran the build again straight away, the timestamp server usually responds just fine, the server availability issue is usually transient and the retry option with a suitable pause resolves this issue nicely. It makes no sense to use this option on a compiler action though, as the result would most likely not change.

I wish I could define local Variables!

In FinalBuilder 7, you can! The Action Group action in FB7 allows you to define local variables. These variables are then available to all child actions of the Action Group action.


How can I capture and process the output of my custom executable?

We get ask this one quite often, so I guess we haven't done a great job of publicising the Output Monitors feature. Output Monitors are available on all actions, and they allow you to process the logged output of the action. A typical example of the use of output monitors might be to fail an action if a particular bit of text is output from the action.


Variable Suggestion (F12)

This is another one of those features that has been there a while but is not well known. I showed this feature to some of the newer developers here last week and got lots of "oh wow, I never knew that" type responses. I have to admit I'd forgotten about it myself until I started looking for ideas for this post! The way it works is that pressing F12 on a text field will drop down a list of suggestions on variable usage. The list is weighted so that variables that replace the most of the original string will list at the top. This is a great help in making sure you don't hard code paths when the project needs to run on another machine.


FinalBuilder has had an NUnit action for some time now, but for DUnit we have always advocated just compiling the unit test executable as a console app using the TextTestRunner, and using the Execute Program action. This has worked fine, however it doesn't provide the same sort of integration into FinalBuilder Server as the NUnit action provides.

FinalBuilder or later includes a new DUnit action. This action is designed to run DUnit test applications that are written as console apps, and use the FinalBuilder.XMLTestRunner.pas file to run the unit tests. This unit produces and xml report file in the same format as NUnit, which means that FinalBuilder already knows how to parse it. Also included in the FinalBuilder\DUnit folder is an XSL stylesheet and a CSS file to transform the xml report file to html (which can be done using the TransformXML action. The FinalBuilder.XMLTestRunner is a combination of the xml test runner and the text test runner. It still writes out to the console (which the action sends to the FinalBuilder log) and it also writes the xml report file.

When the DUnit action is used under FinaBuilder Server 7.x - the DUnit results are shown on the Status page :

and in a separate tab on the Build Log page :

The Passes and Failures can be inspected by clicking on the green or red buttons.

The FinalBuilder\DUnit folder also includes a simple example test application which shows how to structure your test executable to use the FinalBuilder.XMLTestRunner.

FinalBuilder is available here - disclaimer - please note it is a Test build, which means it's a build which contains bug fixes and or new features since the last official update, but has not had the same testing applied to it as an official update build would.