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

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

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 2

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 3

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 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.