2009-07-22 8 views
2

Ich baue ein dediziertes Projekt für alle Komponententests unseres Hauptprojekts, da die Einbeziehung in das Hauptprojekt eine bereits große Belastung bedeuten würde Codebasis. Jetzt werden alle Einheiten des Hauptprojekts in der dpr-Datei des Projekts mit ihren Standorten referenziert. Wenn ich einen Testfall für eine Klasse schreibe, kopiere ich einfach die Klasseneinheitsreferenz (und die referenzierten Einheitseinheitsreferenzen) aus dem Hauptprojekt dpr und füge sie in das Einheitentestprojekt ein.Delphi: Wie man alle Einheiten und Einheitenreferenzen eines Projekts in einem anderen Projekt verwendet

Dies bedeutet, dass ich am Ende mit einer dpr-Datei enden wird, die alle Hauptprojekte dpr-Dateien Unit-Referenzen verbatim enthält, die schwer zu pflegen sein wird, wenn die wichtigsten Projekte dpr ändert. Wir sprechen hier von Tausenden von Einheiten.

Meine Frage ist, kann ich irgendwie alle Einheitenreferenzen eines Projekts in ein anderes Projekt aufnehmen? Einfach das Hauptprojekt kompilieren seine dcus in einem Verzeichnis und dies in der Einheit Tests Projekte dcu Suchpfad ist nicht ausreichend, da die Einheiten haben Initialisierungsroutinen, die ausgeführt werden müssen.

Antwort

2

Die Art, wie ich dies implementieren würde, würde ein Programm erstellen, um eine vorhandene DPR-Datei zu nehmen und eine Include-Datei zu generieren, die ich dann in meiner Testanwendung verwenden würde. Sie können wahrscheinlich das meiste davon mit einer tStringlist machen. Dieses Projekt wird VOR dem Erstellen Ihrer Testfälle ausgeführt.

var 
    OrigDpr : tStringlist; 
begin 
    OrigDpr := tSTringlist.create; 
    OrigDpr.LoadFromFile(originalprojectname); 
    while (OrigDpr.Count > 0) and (not SameText('uses',OrigDpr.Strings[0])) do 
    OrigDpr.Delete(0); 
    // delete the uses line. 
    if (OrigDpr.Count > 0) then 
    OrigDpr.Delete(0); 
    while (OrigDpr.Count > 0) and 
     (not SameText('{$R *.RES}',OrigDpr.Strings[OrigDpr.Count-1]) do 
    OrigDpr.Delete(OrigDpr.Count-1); 
    // delete the $R reference 
    if (OrigDpr.Count > 0) then 
    OrigDpr.Delete(OrigDpr.Count-1); 

    OrigDpr.SaveToFile('pathtotestproject\TESTPROJECT.INC'); 
end; 

Fügen Sie dann in Ihrem Test DPR den folgenden Code in Ihre Projektverwendungsklausel ein. Da die uses-Klausel enthalten bereits Datei das Semikolon enthält, verwenden Sie die Datei am Ende der normalen Testeinheiten umfassen .:

USES 
    // test units go FIRST 
    {$I pathtotestproject\TESTPROJECT.INC} 

Meine Vermutung ist, dass Sie ausführen spät/lose Bindung, weshalb dies alles ist in erster Linie notwendig (die Einheiten sind nicht anders als in der DPR referenziert). Andernfalls wäre nur die Verwendung einer der Einheiten ausreichend, um den Initialisierungscode ausführen zu lassen.

EDIT

Ein andere Möglichkeit wäre das erste Programm erzeugt eine komplette Einheit haben, und dann dieses Gerät in der Testanwendung verwenden. Dies kompiliert den Initialisierungs-/Finalisierungscode von allen referenzierten Einheiten. Ihre Testanwendung müsste dann das von Ihnen erwähnte globale Repository verwenden, um auf diese Objekte zuzugreifen.

Ein wichtiger Teil hier ist, sicherzustellen, dass der Suchpfad des Testprojekts die Quellverzeichnisse für das andere Projekt enthält.

+1

Ja, ich dachte darüber nach, so etwas zu tun. Leider sind sie nicht Teil des Projekts für die IDE, wenn ich sie mit der Compiler-Direktive einschließe, vielleicht modifiziere ich dein Beispiel, damit es das dpr des Testprojekts direkt ändert. Es gibt keine späte Bindung, ich möchte alle Einheiten für ihren Initialisierungscode einschließen, auch diejenigen, die (noch) keine Tests haben. Es gibt eine globale Klassenregistrierung, die ich verwenden möchte. Außerdem möchte ich es meinen Kollegen erleichtern, neue Tests zu schreiben, ohne sich mit Unit-Referenzen auseinandersetzen zu müssen, wäre ein Hindernis weniger. – Ozan

2

Nein, es gibt keine Möglichkeit, dies zu tun (gut), aber es kann nicht viel ausmachen. Die IDE behält den DPR bei, und es ist unglaublich heikel, wie die Dinge referenziert werden. Techniken, die in anderen Einheiten funktionieren, wie z. B. Dateien, funktionieren nicht zuverlässig in der DPR. Sie werden sicher kompilieren, bis Sie etwas tun, was die IDE dazu bringt, die DPR zu modifizieren, und zu diesem Zeitpunkt kann der DPR-Code fehlerhaft sein.

Es ist jedoch nicht unbedingt notwendig, jede referenzierte Datei in den DPR aufzunehmen. Es ist eine gute Idee, da es die IDE glücklicher und schneller macht, aber wenn die DPR nur auf Ihre Tests referenziert und die Tests die Einheiten Ihres Hauptprojekts referenzieren, würde alles noch funktionieren.

+0

Auf der anderen Seite, wenn eine Einheit im .dpr mit z. Ein falscher Weg, man kann furchtbar seltsame Errorsgs bekommen. –

+0

Wenn die Tests die Einheiten des Hauptprojekts referenzieren, müssten sie sie mit ihrem Pfad referenzieren, was meines Wissens nur im dpr möglich ist. – Ozan

+0

Nein, tun sie nicht. Sie können dafür die Projektsuche verwenden. –

0

Ich behalte immer die Anzahl der Referenzen in der.dpr minimal:

  • Einheiten, die wichtige Initialisierungen
  • Einheiten haben, die in VFI Erbe
  • Einheiten beteiligt sind, die die automatischen instanziiert Formen.
  • manchmal ein paar zentrale Einheiten, um schnell mit ctrl-enter den Geschäftscode zu navigieren.

und immer mit so minimalen (relativen) Pfaden wie möglich.

Das funktioniert im Allgemeinen mit nur einem kleinen Problem, Durchsuchen nach Einheiten über Datei-> öffnen manchmal vermasselt das aktuelle Arbeitsverzeichnis und damit die "Wurzel" für die relevanten Pfade. Eine Problemumgehung besteht darin, eine Datei-> Öffnen einer Einheit in den Basedirs zu machen.

Verwandte Themen