How to use the DUnitX VCL GUI test runner for Delphi to run and view unit tests | OCERIS

2021-09-08T00:00:00Z

DUnitX is an excellent unit test framework for Delphi created by Vincent Parrett who created the equally excellent products FinalBuilder and Continua CI. I had written my own test framework but found it lacking compared to the more fully developed DUnitX. I ended up adopting DUnitX for all my unit test projects for Delphi. The only thing I found myself missing was the GUI that I had developed for my framework. After some consideration, I decided to port what I had to work with DUnitX. I primarily created this post to address converting existing console based projects to use the GUI runner instead. Even though DUnitX is now included with Delphi, there isn’t much documentation on the steps to actually get the GUI runner up and running.

Option 1: Create a New Project

One thing that was updated after adding the new runner was the project wizard that creates DUnitX projects. Selecting DUnitX Project from the File->New dialog in Delphi will show the wizard - which has an option for the VCL runner built-in.

Selecting it will generate the project code necessary to use the GUI runner by default.

Option 2: Convert an Existing Project

Converting an existing DUnitX project to use the GUI runner is fairly easy, just not thoroughly documented.

Step 1: Include the GUI PAS File in the Project Uses

Include DUnitX.Logger.GUI.VCL near the top of the uses clause in your project’s dpr file.

uses
  SysUtils,
  DUnitX.Loggers.GUI.VCL,
  DUnitX.Loggers.Console,
  DUnitX.Loggers.Xml.NUnit,
  DUnitX.TestFramework,

Step 2: Call the Run Procedure

Next, in the body of your project file (between begin and end) you’ll want to include:

    DUnitX.Loggers.GUI.VCL.Run;
    exit;

The GUI runner pas file has all the logic to create the runner and start the tests in the Run procedure.

Combining with Continuous Integration

These days, your project is probably running under continuous integration and will be reliant on the console runner of DUnitX. Using various conditionals, you can make a project that will work for just about every use case. Below is a sample of my common boilerplate for all my DUnitX projects.

program SyncBlock.Tests;

//<SyncBlock id="OCERIS.Delphi.DUnitX.Project.AboveUses" version="Delphi.XE">
{$IFDEF CI}
  {$APPTYPE CONSOLE}
{$ELSE}
  {$IFNDEF GUI}
    {$IFNDEF TESTINSIGHT}
      {$APPTYPE CONSOLE}
    {$ENDIF}
  {$ENDIF}
{$ENDIF}

{$STRONGLINKTYPES ON}

{$R *.res}
//</SyncBlock>

uses
  FastMM4,
  SysUtils,
  DUnitX.Loggers.GUI.VCL,
  DUnitX.Loggers.Console,
  DUnitX.Loggers.Xml.NUnit,
  DUnitX.TestFramework,
  //<snip> - project specific files here
  CodeSiteLogging;

//<SyncBlock id="OCERIS.Delphi.DUnitX.Project.BelowUses" version="Delphi.XE">
var
  runner : ITestRunner;
  results : IRunResults;
  logger : ITestLogger;
  nunitLogger : ITestLogger;

begin
  Assert.IgnoreCaseDefault := False;

{$IFDEF CI}
  CodeSiteManager.Enabled := False;
{$ELSE}
  {$IFDEF GUI}
    DUnitX.Loggers.GUI.VCL.Run;
    exit;
  {$ENDIF}

  {$IFDEF TESTINSIGHT}
    TestInsight.DUnitX.RunRegisteredTests;
    exit;
  {$ENDIF}
{$ENDIF}

  try
    //Check command line options, will exit if invalid
    TDUnitX.CheckCommandLine;
    //Create the test runner
    runner := TDUnitX.CreateRunner;
    //Tell the runner to use RTTI to find Fixtures
    runner.UseRTTI := True;
    //tell the runner how we will log things
    //Log to the console window
    logger := TDUnitXConsoleLogger.Create(False);
    runner.AddLogger(logger);
    //Generate an NUnit compatible XML File
    nunitLogger := TDUnitXXMLNUnitFileLogger.Create(TDUnitX.Options.XMLOutputFile);
    runner.AddLogger(nunitLogger);
    runner.FailsOnNoAsserts := True; //When true, Assertions must be made during tests;

    //Run tests
    results := runner.Execute;
    if not results.AllPassed then
      System.ExitCode := EXIT_ERRORS;
  except
    on E: Exception do
      System.Writeln(E.ClassName, ': ', E.Message);
  end;

  {$IFNDEF CI}
  //We don't want this happening when running under CI.
  if TDUnitX.Options.ExitBehavior = TDUnitXExitBehavior.Pause then
  begin
    System.Write('Done...  Press <Enter> key to quit.');
    System.Readln;
  end;
  {$ENDIF}
//</SyncBlock>
end.

Conclusion

Switching to the GUI runner isn’t hard - you just have to know what pieces to put where. Making it co-exist with CI is also pretty simple once you have a working example. Hopefully the above information will make it a bit easier to do both.

Speed up your TypeScript or JavaScript Jest unit tests with these simple changes | OCERIS

2021-09-10T00:00:00Z

Jest is my current choice for unit testing JavaScript and TypeScript projects (using ts-jest). I particularly like that it has everything baked in and does not require separate assertion or mock libraries. However, one thing that I was not particularly fond of was the speed.

The Problem

On a recent TypeScript project (a small library of utility functions), I started to notice that my unit tests were taking much longer than expected. This project is new, relatively small, an only contained 38 unit tests across 5 files. The run would consistently take over 16 seconds to complete on a development machine with extremely high-end specs.

Test Suites: 5 passed, 5 total
Tests:       38 passed, 38 total
Snapshots:   0 total
Time:        16.586 s

I tried a lot of things in my jest.config.ts file, including limiting the search folder to only look in my src directory, and even reordered the moduleFileExtensions to include TypeScript files first per the Jest documentation.

import type { InitialOptionsTsJest } from 'ts-jest/dist/types';

const config: InitialOptionsTsJest = {
  globals: {
    'ts-jest': {},
  },

  preset: 'ts-jest',
  displayName: 'OSAS-TypeScript',
  testEnvironment: 'node',
  roots: ['<rootDir>/src/'],
  testMatch: ['**/*.Tests.ts?(x)'],
  moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node'],
};

export default config;

The file above is what I ended up with, but the tests still took around 16 seconds to run.

The Solution

After much searching, I found a lot of people have the same issue, and a lot of suggestions of things to try. Most actually didn’t have any affect on the speed, but two configuration changes did.

I modified my jest.config.ts file with the two options highlighted:

import type { InitialOptionsTsJest } from 'ts-jest/dist/types';

const config: InitialOptionsTsJest = {
  globals: {
    'ts-jest': {
      isolatedModules: true,
    },
  },

  preset: "ts-jest",
  displayName: "OSAS-TypeScript",
  testEnvironment: "node",
  roots: ["<rootDir>/src/"],
  testMatch: ["**/*.Tests.ts?(x)"],
  moduleFileExtensions: ["ts", "tsx", "js", "jsx", "json", "node"],
  maxWorkers: "50%",
};

export default config;

Just those changes yielded a 95% increase in speed with the test run now consistently running in under a second.

Test Suites: 5 passed, 5 total
Tests:       38 passed, 38 total
Snapshots:   0 total
Time:        0.767 s

So What’s the Catch?

maxWorkers: “50%”

There isn’t really a catch to this setting. It reduces the default number of simultaneous threads used to run tests which, in most cases, yields better performance. In fact, in most cases it yields a 20% increase in performance by itself.

isolatedModules: true

This setting does have a significant caveat - it compiles each file separately which disables type-checking and some other features but, as you can see, results in a huge performance boost. This may or may not be what is needed for your project, so use accordingly.

Development Blog | OCERIS