The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,512 other followers

Archive for the ‘Event’ Category

Some Delphi unit testing notes

Posted by jpluimers on 2019/03/21

A few notes I wrote down when coaching a team to write better unit tests and test tooling form themselves.

  • unit tests test a unit of code
  • integrating tests test multiple units of code, which can go as far as having external dependencies
  • mocks simulate depencencies
  • unit tests are being executed by a unit test runner
  • you can group tests into test suites, which can contain other suites, and determine order of tests (which can be important for integration tests).
  • unit tests and suites register them to be eligible for running (a test without an encompassing suite presents itself as a suit with one test)
  • the runner optionally has a mechanism to filter the eligible suites and tests down to the ones actually being run

References:

In the particular case for this team, testing was mostly done using DUnit for Delphi.

Here, these are worth mentioning:

  • The configuration is not limited to the GuiTestRunner: any DUnit based test runner can use it (though the default console TextTestRunner skips it, but https://github.com/graemeg/fptest/blob/master/src/TextTestRunner.pas and https://github.com/VSoftTechnologies/DUnit-XML/blob/master/Example/DUnitXMLTest.dpr shows how it can be used).
    • It comes down to either Suite.LoadConfiguration(IniFileName, UseRegistry, True) or RegisteredTests.LoadConfiguration(IniFileName, UseRegistry, True) where
      • IniFileName contains the INI filename, for instance from ExtractFilePath(ParamStr(0)) + 'dunit.ini' or from a ParamStr parameter on the command-line.
      • UseRegistry usually is False
  • If you want to disable all exceptions for easier debugging, but still want to catch failures, then you can enable Break on Failures (see screenshot below) so breaking tests will throw an EBreakingTestFailure.
  • Registration
    • Per test or per suite
    • You do not need a ITestSuite implementing class in order to register a suite (just pass a SuitePath when registering multiple tests)
    • Basically the only reasons for having a ITestSuite implementing class (like descending from TTestSuite) are
      • to have a specific SetUp or TearDown for that suite level
      • to allow \ backslash or / forward slash in test suite names (which is unwise because a lot of tooling sees those as suite hierarchy separators)
    • function TestSuite(AName: string; const Tests: array of ITest): ITestSuite;
    • procedure RegisterTest(SuitePath: string; test: ITest); overload;
    • procedure RegisterTest(test: ITest); overload;
    • procedure RegisterTests(SuitePath: string; const Tests: array of ITest); overload;
    • procedure RegisterTests(const Tests: array of ITest); overload;
    • function RegisteredTests: ITestSuite;
  • Configuration is exclusion based
    • procedure TTestSuite.LoadConfiguration(const iniFile: TCustomIniFile; const section: string);
    • procedure TTestSuite.SaveConfiguration(const iniFile: TCustomIniFile; const section: string);
    • The configuration file default name is DUnit.ini
    • The DUnit.ini file will be saved after the GUI tests are run (overwriting any changes) when the Auto Save Configuration is enabled (which is the default)
    • All tests are configured in
      • sections
        • named (of course inside [] brackets) as Tests.TestPath, where TestPath either
          • is the name of the test class
          • is a . period separated path of suites ending in an test class
        • values having keys named either
          • the test method with a value 0 to disable the test
          • a test method followed by .RunCount with an integer value indicating how often that test needs to be executed
        • note that with either TestName=1 or TestName.RunCount=1 will disappear from the ini file because those are default values
      • There are no values to indicate tests need to be run (so by default registered tests eligible to be run are being run)
    • An example file (without .RunCount ) is at [WayBack] delphidicontainer/dunit.ini at master · danieleteti/delphidicontainer · GitHub
    • You can add comments to INI files using a semi colon at the start of the line; see [WayBack] Do standard windows .ini files allow comments? – Stack Overflow

Registration and exclusion are two separate concerns.

To configure non-GUI tests, first run the GUI tester, configure it, then copy the resulting DUnit.ini file to the environment where the non-GUI tests are being run.

Be sure to check out test decorators, and maybe amend them with dependency injection. Example for apply database setup/teardown to a full suite of tests: [WayBack] How to organize testing of DB in dUnit — IT daily blog, news, magazine, technologies

Some resurrected documentation links because not all links from [WayBack] DUnit – Xtreme testing for Delphi and [WayBack] DUNIT: An Xtreme testing framework for Delphi programs succeed.

–jeroen

Posted in Agile, Conference Topics, Conferences, Development, Event, Software Development, Unit Testing | Leave a Comment »

delphi – Why was TDataSource created originally? – Stack Overflow

Posted by jpluimers on 2019/03/14

From a while ago [WayBackdelphi – Why was TDataSource created originally? – Stack Overflow

5down voteaccepted

It is all about decoupling and indirection.

And with TDataSource there are two kinds of them:

  • Decoupling the master detail relations (TDataSource is in the same module as the TDataSets that are being bound; the detail TDataSet references the master TDataSet by pointing its’ MasterSource property to the TDataSource that points to the master TDataSet)
  • Decoupling the UI from the business layer (TDataSets are in a DataModule; TDataSource is on the Form/Frame which contains your UI controls, UI controls reference their DataSourceproperty).

Since many components can point to the same DataSource, you can quickly switch which underlying TDataSet they use by just flipping one TDataSource.DataSet property.

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | Leave a Comment »

Smart Pointers code that compiles in FPC and Delphi

Posted by jpluimers on 2019/03/06

Delphi and FPC have different language boundaries, so it is always good to read a thread discussing how to get near-the-edge cases work in both.

This case is about Smart Pointers (here called auto pointers, maybe because auto_ptr is what they used to be called in C++): [WayBack] Hi all, I am trying to make a certain piece of code cross compile between Delphi and FPC. On FPC, it compiles fine but on Delphi I get a [dcc32 Error] P… – Ugochukwu Mmaduekwe – Google+

In the end if comes down to that Delphi does not allow forward-declaration of records (it does for interfaces and classes), but that you do not need a __PAutoPtr_T = ^__TAutoPtr_T, because you can use ^__TAutoPtr_T in parameters.

In Spring4D, they are called Shared/IShared/TShared, see my comment:

Note that since these are reference counted, you might want to call them shared_ptr. If you enforce the single-instance behaviour, observe that in C++ they are now called uniqe_ptr.

In Spring4D this rename has already taken place a while ago: https://bitbucket.org/sglienke/spring4d/commits/e252b81fd3788cf5b82588721f68d00c892deb87

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | 2 Comments »

Application shutdown: wait for all threads to terminate or not?

Posted by jpluimers on 2019/02/21

A while ago, I ran into a problem that an anonymous thread would run longer than the main thread of the application.

This caused all sorts of trouble, so in this case I decided to fix it for that particular thread.

There are various opinions if this should be done for all threads or not. Like always, it depends, so it is good to mention a few:

This particular case resulted into the memory manager shutting down earlier than the anonymous thread, but the anonymous thread was still using memory allocation functions, resulting into a few things of which you do not want the first and second to happen on a continuous integration system:

  1. Error messages during shutdown, which is unwanted on a headless system:
    ---------------------------
    MyIntegrationTests.exe: MM Operation after uninstall.
    ---------------------------
    FastMM has detected a GetMem call after FastMM was uninstalled.
    ---------------------------
    OK 
    ---------------------------

    or

    ---------------------------
    MyIntegrationTests.exe: MM Operation after uninstall.
    ---------------------------
    FastMM has detected a FreeMem call after FastMM was uninstalled.
    ---------------------------
    OK 
    ---------------------------

    either of them followed by

    ---------------------------
    Error
    ---------------------------
    Runtime error 203 at 00408EFF
    ---------------------------
    OK 
    ---------------------------

    or

    ---------------------------
    Error
    ---------------------------
    Runtime error 204 at 0040AFE9
    ---------------------------
    OK 
    ---------------------------

    The errors are mappings of:

    203, { reOutOfMemory }
    204, { reInvalidPtr }
  2. The MyIntegrationTests_MemoryManager_EventLog.txt to rapidly grow to 100s of megabytes.
  3. The MyIntegrationTests_MemoryManager_EventLog.txt not to be truncated.

This particular case was easy to fix by adding a global (but implementation section contained) boolean indicating if the thread was already finished:

unit DebugInformationLoaderUnit;

interface

implementation

uses
  JclDebug;

var
  LoadDebugInformationAsyncFinished: Boolean = False;

procedure LoadDebugInformationAsync;
begin
  TThread.CreateAnonymousThread(
    procedure
    begin
      TThread.NameThreadForDebugging('LoadDebugInforoamtionAsync');
      DebugInfoAvailable(MainInstance);
      LoadDebugInformationAsyncFinished := True;
    end).Start;
end;

initialization
  LoadDebugInformationAsync;

finalization
  while not LoadDebugInformationAsyncFinished do
  begin
    Sleep(1);
  end;
end.

In addition, I did this to suppress message boxes outside Delphi:

program MyIntegrationTests;

...

{$Include FastMM4Options.inc}

uses
  FastMM4 in '..\..\..\Shared\FastMM4.pas',
  System.Classes,
...;

{$R *.RES}

begin
  TThread.NameThreadForDebugging(ParamStr(0));

  SuppressMessageBoxes := SuppressMessageBoxes // follow pattern in FastMM4.FinalizeMemoryManager
    {$ifdef RequireIDEPresenceForLeakReporting}
        and DelphiIsRunning
    {$endif}
    {$ifdef RequireDebuggerPresenceForLeakReporting}
        and ((DebugHook <> 0)
        {$ifdef PatchBCBTerminate}
        or (Assigned(pCppDebugHook) and (pCppDebugHook^ <> 0))
        {$endif PatchBCBTerminate}
        )
    {$endif}
    ;
  {$WARN SYMBOL_PLATFORM OFF} NoErrMsg := {$WARN SYMBOL_PLATFORM ON} SuppressMessageBoxes; // Set RTL message boxes as well;

  ...
end.

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | Leave a Comment »

On my research list: Delphi; automatically generate class body from interface definition

Posted by jpluimers on 2019/01/23

Still need to research this: [WayBack] I search for way to automatically generate class body from interface definition… – Jacek Laskowski – Google+

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, ModelMaker Code Explorer, Software Development | 2 Comments »

 
%d bloggers like this: