There are various AOP frameworks available for each of the three platforms SmartInspect supports, so why did we decide to start with PostSharp for the first part of this blog series about apsect-oriented logging? PostSharp has become the de-facto standard AOP framework for .NET and there are many things to like about PostSharp:

• PostSharp is really easy to use. It integrates nicely with MSBuild (and therefore Visual Studio) and you just need to complete the PostSharp setup and are good to go.
• It provides different APIs depending on what you are trying to accomplish. You can use a low-level API for injecting snippets of MSIL code for complexer tasks (PostSharp.Core) or a very simple high-level API (PostSharp.Laos) to develop aspects with custom .NET attributes.
• It’s very well documented. The APIs are fully documented and there are getting started tutorials, videos, a plugin repository and lots more. Can’t get a lot better than that.
• It’s a compile-time AOP framework. Unlike other tools which inject the AOP code at runtime, it post-processes the assemblies directly after compliation which is more efficient and allows for more flexibility.
• Last but not least, some SmartInspect customers were already successfully using PostSharp in their applications and told us that they liked the combination of both tools (that’s how we became aware of PostSharp in the first place).

We will be using the simpler Laos API for our SmartInspect PostSharp aspects, as we found it sufficient for all our needs. The resulting library is able to automatically trace method execution, log exceptions and watch changes of field variables. The library comes with three aspects for the different tasks, each implemented as a custom .NET attribute.

Using the SmartInspect aspects

The general procedure of using a PostSharp aspect is to install the PostSharp framework and to add the PostSharp.Public and PostSharp.Laos assembly references to your application. PostSharp injects itself into the MSBuild build process and automatically processes all assemblies that reference PostSharp.

For our logging aspects, you further need to add references to the Gurock.SmartInspect and Gurock.SmartInspect.PostSharp assemblies (the logging library and PostSharp aspects, respectively). The logging library is included in the SmartInspect trial download and the SmartInspect AOP plugin can be downloaded from the SmartInspect resources page.

Tracing method execution

The first aspect I am going to demonstrate is for tracing method execution. This aspect makes it really easy to generate a complete call trace of your application, showing you the entire application flow and letting you inspect stack traces at each execution point. It automatically generates two log messages for each method call: one for entering a method and one when a method exits. You can also log the passed method arguments (when entering a method) and the method result (when exiting a method), respectively.

To use this aspect, simple add the SiTrace custom attribute to your application as follows (note how you can continue to use SmartInspect for complementary log messages, of course):

using System;
using Gurock.SmartInspect;
using Gurock.SmartInspect.PostSharp;

[assembly:SiTrace(SessionName="Main")]

namespace Gurock.SmartInspect.PostSharp.Samples
{
	class Program
	{
		static void Main(string[] args)
		{
			SiAuto.Si.Enabled = true; // Enable logging
			Hello("World");
			Goodbye("World");
		}

		static void Hello(string name)
		{
			SiAuto.Main.LogMessage("Hello, {0}.", name);
		}

		static string Goodbye(string name)
		{
			string msg = String.Format("Goodbye, {0}.", name);
			SiAuto.Main.LogMessage(msg);
			return msg;
		}
	}
}

The attribute can be specified on a per-class/per-method basis or, like in our example, for the entire assembly. You can further specify filters for including/excluding certain modules/classes (called attribute targets in the PostSharp terminology), set aspect priorities (useful with nested aspects) and much more.

Our aspects have a few additional SmartInspect-related options. First, as you can see in the example above, you can set the session name used for sending log messages. If you do not want a hard-coded session name, you can tell the aspect to make use of the logging context and automatically adjust the name based on the current namespace or class. You can do so by setting a so called session policy. For example, to automatically use a session name that equals the name of the current class context, you can use a session policy of SessionPolicy.TypeName and omit the session name:

...
[assembly:SiTrace(SessionPolicy=SessionPolicy.TypeName)]
...

There are additional options for including the method arguments (IncludeArguments) and method return value (IncludeReturnValue). With both options enabled, the resulting log looks as follows in the SmartInspect Console (SmartInspect’s viewer application). Note how the automatic enter/exit messages are mixed with the manual log messages:

The SiTrace sample log shown in the SmartInspect Console

Logging exceptions

Another typical use-case for logging is recording all occurring exceptions and this is usually done by adding log calls to your exception handlers. Adding log statements to all your exception handlers can get tedious and error-prone though (e.g., you could forget to rethrow the exception after logging it), so we’ve added an aspect to automate this task for you. To use it, just add the SiException attribute to your code:

using System;
using Gurock.SmartInspect;
using Gurock.SmartInspect.PostSharp;

...

[assembly: SiException(SessionName="Main")]

...

		static void Hello(string name)
		{
			SiAuto.Main.LogMessage("Hello, {0}.", name);
			throw new Exception("This is a test exception");
		}

...

Note how the exception is now automatically included in the resulting log (within the expected method context):

The SiException sample log shown in the SmartInspect Console

Watching field values

Arguably the most advanced aspect in this library is the SiField attribute. This attribute lets you automatically record any changes to values of object or class fields. The aspect gets notified whenever the value of a field changes and then logs the name of the field along with its old and new value. You can configure whether the aspect should send the name and values as normal log messages or as SmartInspect watches (for showing the latest values of a variable in the watches toolbox or for displaying its history as a chart in the watches graph). By default, both watches and normal messages are logged.

Let’s have a look at the following example which demonstrates SiField in practice. Note how we use SiField as an attribute for the entire assembly again. We could also limit it to individual classes or fields, either by writing the attribute above the classes/fields we want to inspect or by specifying filters/attribute targets for the global attribute.

using System;
using Gurock.SmartInspect;
using Gurock.SmartInspect.PostSharp;

[assembly: SiField(SessionName = "Main")]

namespace Gurock.SmartInspect.PostSharp.Samples
{
	class Program
	{
		public static int FIELD;

		static void Main(string[] args)
		{
			SiAuto.Si.Enabled = true; // Enable logging
			Counting();
		}

		static void Counting()
		{
			Random r = new Random();

			for (int i = 0; i < 10; i++)
			{
				FIELD = r.Next(100);
				Thread.Sleep(1000);
			}
		}
	}
}

And here’s the generated log in the SmartInspect Console:

The SiField sample log shown in the SmartInspect Console

As you can see, every field change is automatically logged and shown in the Console. The watches toolbox in the lower left of the Console displays the latest value of FIELD in addition to the normal log messages in the main view. Also note the watches graph on the right that displays the field’s history as a chart (with its values over time). I believe an upcoming version of PostSharp will also be able to watch properties and we will update our library accordingly when this feature is available.

The nice thing about these aspects is that they can be freely combined as you like. You can mix and match the aspects as needed. If you plan to use our aspects and library, I also recommend taking a look at the PostSharp documentation for more details about aspects, AOP and PostSharp in general as well as how to configure PostSharp for more complex scenarios.

Feel free to send me an email or leave a comment on this blog in case you have any questions about this plugin.

Switching to a new logging library is not an easy task if you have to replace all existing logging calls with new ones. Luckily, you can extend log4net with custom appenders that allow you to route the log messages to a new destination, for example, to SmartInspect. We have developed such an appender (two, actually) and demonstrate how to use them in a new article:

Using a Custom Log4net Appender with SmartInspect

We hope this will make it a lot more attractive for .NET developers to port existing projects that make use of the classic log4net log framework to SmartInspect.

Another issue with logging is that adding all those log calls takes time and getting a good log coverage can get tedious when instrumenting a large existing application. That’s not necessarily the case if you add logging from the very beginning of development, but let’s face it, most applications have already reached a mature state before you think of adding diagnostics and logging features. Adding such features often comes as an afterthought (which it shouldn’t, ideally), so when you or a customer experience a problem which you cannot easily reproduce, you are instrumenting your application or parts of it and that isn’t any fun at all. We usually recommend instrumenting the most important parts of an application first and then building from there, but it’s still, well, time-consuming.

Fortunately, there are approaches and techniques to solve both of these problems, with one of the most promising being aspect-oriented programming (or AOP for short):

“Aspect-oriented programming (AOP) is a programming paradigm that increases modularity by enabling improved separation of concerns. This entails breaking down a program into distinct parts (so-called concerns, cohesive areas of functionality). All programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g. procedures, modules, classes, methods) that can be used to implement, abstract and compose these concerns. But some concerns defy these forms of implementation and are called crosscutting concerns because they “cut across” multiple abstractions in a program.”

It’s been several years since I first heard about AOP. Back then, AOP was being marketed as one of the next big things in programming (okay, it’s been several, several years now). Supporters of AOP claimed it would change programming and software development as much as object-oriented programming did 20 years ago. We now know that it hasn’t and probably never will to that extend, but it’s for sure a nice addition to the developer’s toolbox.

So, what’s so special about AOP? The most beautiful aspect of AOP is that it improves the modularity of your application by putting parts that logically belong together in one central location. You can implement security concepts, caching, transactions, design by contract and of course a complete logging solution without touching any of your existing classes or methods. This means there’s no need for repeated boiler plate code for checking method arguments for null values, no repetitions of the same begin/commit/rollback transaction code or for adding exception logging code to every exception handler. You simply tell the AOP framework which parts of your application should make use of which features (also called aspects in AOP terminology) and the AOP framework does all the work wiring those aspects to your application modules.

In the coming weeks, we will take a look at some of the available AOP frameworks for the different platforms supported by SmartInspect here on this blog and show how to build a sophisticated logging layer with these frameworks and our own logging tool SmartInspect. Stay tuned!

Porting an existing application with thousands of log4j log statements isn’t easy if you have to replace each and every log call. To make it easier to switch to SmartInspect, we are now providing custom log4j appenders that can be used to forward all log messages to SmartInspect. Once you include and configure one of our appenders, you can benefit from SmartInspect’s infrastructure and, depending on which appender you use, also directly benefit from SmartInspect’s additional logging capabilities.

We hope this will make it a lot easier to port existing projects that make use of the classic log4j log framework to SmartInspect. Take a look at the full article here:

Writing a Custom Log4j Appender for SmartInspect

Unfortunately, Delphi never had good (built-in) run-time support for stack traces. The features for stack traces during debugging in the IDE are/were okay, but there were nothing in the language or framework which helped you to find out programmatically where an exception occurred at run-time and, more importantly, how it got passed to your exception handler (besides the original exception address, maybe). So, I was happy to see that Delphi 2009 finally introduced a new StackTrace property which, I hoped, would return a full-blown stack trace when you caught an exception.

The initial happiness soon wore off when I realized that the StackTrace property was really just a placeholder to return a stack trace from a possible stack trace provider rather than a real stack trace implementation. So, without such a provider (and there’s none that comes directly with Delphi), there is still no way to get a stack trace for your exceptions. Though a bit disappointing, the good thing is that there’s now finally a standardized way to get a stack trace, even if it’s not implemented by default.

Exception reporting tools such as Eurekalog or madExcept or debug helpers such as the JclDebug unit can register themselves as providers and use their engines to return a stack trace when an exception is raised. I’ve built a small unit which demonstrates this with the Jcl in combination with our logging tool SmartInspect and I’ve heard Fabio of Eurekalog is working on a similar feature for his component:

unit StackTrace;

interface

uses
  SysUtils, Classes, JclDebug;

implementation

function GetExceptionStackInfoProc(P: PExceptionRecord): Pointer;
var
  LLines: TStringList;
  LText: String;
  LResult: PChar;
begin
  LLines := TStringList.Create;
  try
    JclLastExceptStackListToStrings(LLines, True, True, True, True);
    LText := LLines.Text;
    LResult := StrAlloc(Length(LText));
    StrCopy(LResult, PChar(LText));
    Result := LResult;
  finally
    LLines.Free;
  end;
end;

function GetStackInfoStringProc(Info: Pointer): string;
begin
  Result := string(PChar(Info));
end;

procedure CleanUpStackInfoProc(Info: Pointer);
begin
  StrDispose(PChar(Info));
end;

initialization
  // Start the Jcl exception tracking and register our Exception
  // stack trace provider.
  if JclStartExceptionTracking then
  begin
    Exception.GetExceptionStackInfoProc := GetExceptionStackInfoProc;
    Exception.GetStackInfoStringProc := GetStackInfoStringProc;
    Exception.CleanUpStackInfoProc := CleanUpStackInfoProc;
  end;

finalization
  // Stop Jcl exception tracking and unregister our provider.
  if JclExceptionTrackingActive then
  begin
    Exception.GetExceptionStackInfoProc := nil;
    Exception.GetStackInfoStringProc := nil;
    Exception.CleanUpStackInfoProc := nil;
    JclStopExceptionTracking;
  end;
end.

The unit merely starts and stops the exception tracking of the Jcl, implements a minimal stack trace provider and registers for the Exception provider events. The GetExceptionStackInfoProc and CleanUpStackInfoProc functions are automatically called by the RTL to give the provider the opportunity to initialize and cleanup the stack trace after an exception occurred. GetStackInfoStringProc is called indirectly when you access the StackTrace property and is responsible for returning the actual stack trace.

So, how do you use this unit? Let’s have a look at the following example:

...

uses
  ..., StackTrace;

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    procedure SomeMethod;
  end;

implementation

procedure TForm1.Button1Click(Sender: TObject);
begin
  try
    SomeMethod;
  except
    // Log the exception: We use SmartInspect here because it has
    // built-in support for Exception.StackTrace but you could also
    // access the StackTrace property here directly.
    SiMain.LogException;
  end;
end;

procedure TForm1.SomeMethod;
begin
  raise Exception.Create('A test exception');
end;

...

As you can see, using this unit is just a matter of adding it to our uses clause. It won’t get any simpler than that. The unit will take care of registering/unregistering itself as a stack trace provider and when you now access the StackTrace property of an Exception object, you will get a detailed stack trace. To include the method names and line numbers in the stack trace, make sure to let the linker include debug symbols into your application and to enable the ‘Use debug .dcus’ option in case you also want line numbers from the VCL and RTL methods.

The SmartInspect Console showing the stack trace of an exception

Now, when you use SmartInspect for logging and have a stack trace provider registered, all your logged exceptions automatically include the exception’s call stack. Pretty useful, isn’t it?

Test Plans and Configurations

The new support for test plans and configurations makes it a lot easier to run your test suites and cases against multiple configurations such as web browsers, operating systems or hardware platforms. Additionally, test plans allow you to start multiple test runs at once and makes it easy to organize related runs into groups.

We are still looking into making a few smaller changes to this feature, so please let us know what you think by providing feedback in the beta forum or by contacting us.

Upgrading to the new version

To update your TestRail beta installation, please download the new version from your private beta link and follow the upgrade instructions. TestRail is updated by copying the new installation files over your existing TestRail installation. The database upgrade wizard is automatically started when you access TestRail with your web browser. If you haven’t applied for the TestRail beta yet, feel free to do so as we are still looking for new beta participants.

What’s Next?

In the next phase of the TestRail beta we plan to improve the application structure where needed and make it easier to work with test suites and cases. We plan a range of improvements in this area so stay tuned! If you are looking for any particular change in handling test suites and cases (such as linking/copying/organizing) and haven’t provided feedback yet, please let us know.

We are thinking about introducing support for configurations and test plans (in addition to TestRail’s test suites and runs) in the TestRail beta and ask for your feedback and comments. Please see my forum posting with details and mockups of the new feature. If you are participating in the TestRail beta, if you have used similar tools in the past or if you just want to share your comments and ideas, please post your feedback to the TestRail forum. Thanks!

As usual, existing SmartInspect customers can download the new release from our customer portal. If you are interested in giving SmartInspect a try, please download the updated trial version with Delphi 2010 support from our website.

So what do you need to install and run TestRail? As TestRail is a web application based on PHP, you will need a standard server system (most Unix/Linux systems will do, or Windows Server 2003 / 2008), a database (TestRail supports MySQL and MS SQL Server) and of course a web server (Apache or IIS). We recommend setting up a virtual machine with Windows Server or a Linux system such as Ubuntu if you don’t already have a spare server for testing (a desktop OS will also do for testing purposes). You can learn more about TestRail’s requirements and on how to install the product in the TestRail Admin Manual.

Releasing a new software product is always a bit scary and definitely exciting, even if it’s just a beta version for now. So we are really looking forward to your feedback and are curious to find out what you think. Feel free to drop us an email if you have any questions or directly apply to download and install TestRail here:

Apply for the TestRail beta

“Overall the microsites are a great success for us and are an impressive testament to how important keywords in the domain name really are for Google. We already plan to launch additional microsites for SmartInspect and for our upcoming test management software TestRail.”

Read my full guest posting about microsites on 47 Hats.