Bei Verwendung von Delphi IDE wird SQLConnection.Connected automatisch auf "true" gesetzt, wenn Feld- oder Tabellenlisten in verschiedenen Eigenschaften ausgefüllt werden.
Da ich nicht mit Connected = true freigeben möchte, muss mein Dunit-Test fehlschlagen, wenn TSQLConnection.Connected in dfm wahr ist.
Ich löse das auf andere Weise. Ich habe ein kleines Dienstprogramm geschrieben, das eine DFM-Datei lädt und nach Eigenschaften sucht, die nicht vorhanden sein sollten. Einschließen der database.connected = true-Werte.
Dies kann geändert werden, um mit geeigneten Eigenschaften zu arbeiten. Ich habe auch den Kern des Codes hier eingefügt.
Um dies wirklich nützlich zu machen, sollten Sie dieses Dienstprogramm in Ihrem Build-Skript verwenden (ich benutze FinalBuilder). Mein Skript beginnt mit dem Schleifen von .dfm-Dateien, entfernt alle diese Eigenschaften und kompiliert dann die Komponententests. Wenn sie bestehen, wird die Hauptanwendung fortgesetzt. Für mich ist dies ein besserer Weg, als einen Komponententest fehlschlagen zu lassen, da Sie von einem garantiert bekannten guten Punkt ausgehen können.
%Vor%Sie könnten Ihren eigenen Nachkommen von TSQLConnection schreiben, der seine Connected-Eigenschaft nicht speichert:
%Vor%und verwenden Sie diese Komponente anstelle von TSqlConnection.
(Das obige ist für TAdoConnection, aber TSQLConnection sollte auch gut funktionieren.)
OpenCTF - Component Test Framework für Delphi könnte interessant sein, es erstellt automatisch Komponententests für bestimmte Eigenschaften aller Komponenten in allen Formen / Datamodule. Es ist Open Source und einfach zu bedienen.
"Erste Schritte" Dokument: Ссылка
Das OpenCTF-Komponententestframework hilft, automatische Tests für alle zu erstellen (visuelle und nicht visuelle) VCL-Komponenten in einer Delphi-Anwendung. Es basiert auf dem DUnit-Framework.
Einige Anwendungsbeispiele:
Ein weiterer Ansatz für dieses Problem besteht darin, einen Pre-Commit-Hook in Ihren SCM zu implementieren. Ich benutze TortoiseSVN, und ich habe ähnliche Dinge getan, um zu verhindern, dass sich Dinge einschleichen. Zum Beispiel haben wir eine "Skins" -Bibliothek, die versucht, jedem Formular, das Sie in der IDE öffnen, etwa ein Dutzend Skin-Einheiten hinzuzufügen. (Wir haben einen Registry-Patch, der dieses Verhalten "behebt", aber es wird ab und zu "un-erledigt", wenn ein Entwickler Komponenten neu installiert). Also habe ich eine "Liste verbotener Strings" in einer INI-Datei, die sich in einem SVN-Pre-Commit-Hook befindet.
In unserer Umgebung ist der gesamte Produktionscode auf einer dedizierten "Build-Maschine" aufgebaut. Wenn Code also nicht eingecheckt wird, gelangt er nicht in den Build. Problem gelöst.
