How to make Delphi DUnit test fail when TSQLConnection.Connected = true

Question

When using Delphi IDE, it will silently change SQLConnection.Connected to "true" when populating field or table lists in various properties.

Since I don't want to release with Connected = true, I need my dunit test to fail when TSQLConnection.Connected is left true in dfm.

Answer 1

I solve this in another way. I wrote a little utility that loads a DFM file, and looks for properties that should not be present. Including the database.connected = true values.

This can be modified to work with any appropriate properties. I have put the core of the code here too.

To make this really useful, you should use this utility in your build script (I use FinalBuilder). My script starts by looping on .dfm files, stripping any of these properties, and then it compiles and runs the unit tests. If they pass, then it continutes to build the main application. To me, this is a better way than having a unit test fail, as you can start off from a guaranteed known good point.

nState := 0;
bFound := False;
for nFileLoop := 0 to memoFile.Lines.Count - 1 do
begin
  szLine := memoFile.Lines[nFileLoop];

  case nState of      //
  0:
     begin
        if(0 <> Pos('TADOConnection', szLine)) then
        begin
           szSeeking := 'Connected';
           nState := 1;
        end
        else if(0 <> Pos('TADOTable', szLine)) then
        begin
           szSeeking := 'Active';
           nState := 1;
        end
        else if(0 <> Pos('TADOQuery', szLine)) then
        begin
           szSeeking := 'Active';
           nState := 1;
        end
        else if(0 <> Pos('TDBISAMTable', szLine)) then
        begin
           szSeeking := 'Active';
           nState := 1;
        end
        else if(0 <> Pos('TDBISAMDatabase', szLine)) then
        begin
           szSeeking := 'Connected';
           nState := 1;
        end
        else if(0 <> Pos('TDBISAMSession', szLine)) then
        begin
           szSeeking := 'Active';
           nState := 1;
        end
        else if(0 <> Pos('TDBISAMQuery', szLine)) then
        begin
           szSeeking := 'Active';
           nState := 1;
        end;
     end;
  1 :
     begin
        bFound := True;
        if(0 <> Pos('end', szLine)) then
        begin
           nState := 0;
        end
        else if(0 <> Pos(szSeeking, szLine)) then
        begin
           nPos := Pos('=', szLine);
           if nPos > 0 then
           begin
              memoFile.Lines[nFileLoop] := Copy(szLine, 1, nPos) + ' False';
           end;
        end;
     end;
  end;      // case
end;

Answer 2

GExperts has a "Set Component Properties" expert that we configure to close database connections on every compile. Since doing that, we have not had the problem.

Answer 3

You could write your own descendant of TSQLConnection that does not store its Connected property:

  TdzAdoConnection = class(TADOConnection)
  published
    property Connected stored false;
  end;

and use that component rather than TSqlConnection.

(The above is for TAdoConnection, but TSQLConnection should also work fine.)

Answer 4

OpenCTF - Component Test Framework for Delphi might be interesting, it automatically creates unit tests for specified properties of all components in all forms / datamodules. It is Open source and easy to use.

"Getting Started" document: http://www.habarisoft.com/download/OpenCTFGettingStarted.pdf

The OpenCTF component test framework helps to build automatic tests for all (visual and non-visual) VCL components in a Delphi application. It is based on the DUnit framework.

Some usage examples:

• detect missing or wrong property values - e.g. Buttons without assigned Actions, DataSources without associated DataSet
• detect unassigned event handlers - e.g. missing OnExecute event
• check that all DataSets can be opened
• check the tab order
• find invisible components (e.g. invisible TabSheets which better should be hidden at runtime)

OpenCTF http://www.mikejustin.com/images/OpenCTF.gif

Answer 5

Another approach to this problem is to implement a pre-commit hook into your SCM. I use TortoiseSVN, and I've done similar things to prevent things from sneaking in. For example, we have a "skins" library that tries to add about a dozen skin units to any form that you open in the IDE. (We've got a registry patch that "fixes" this behavior, but it gets "un-done" every once in a while, if a developer re-installs components). So I've got a "banned strings list" in a .ini file that is in a SVN pre-commit hook.

In our environment, all production code is built on a dedicated "build machine", so if code doesn't get checked-in, it doesn't make it into the build. Problem solved.