![]() |
AW: Delphi-Unit-Tests project
Da hast du allerdings Recht. Dann lass es mich so formulieren: Mir ist lieber, jemand schreibt einen Test ohne TestInsight (warum auch immer) als gar keinen Test.
|
AW: Delphi-Unit-Tests project
Ja, das ist natürlich lieber, aber man kann es trotzdem integrieren um das zu vereinfachen.
Die Nutzung davon bleibt optional. Schau dir doch einfach die dpr des DUnit Test Projektes der DEC an, dann siehst du wie's umgesetzt ist. |
AW: Delphi-Unit-Tests project
Zitat:
Vom Ablauf her, sehe ich das aber besonders dann als interessant an, wenn man die IDE-Version wechselt/installiert/patched, oder irgendwelche 3rd Party Tools installiert. Immer dann macht ein Test EINMAL in der IDE Sinn, um dann auch gleich mit TestInsight die Ursache zu erforschen. Danach "sollte" ja Alles stabil bleiben. Ist eine Version dann mal stabil, dann braucht man die eigentlich nicht mehr in der IDE, das stimmt. Aber es sollte sich ja auch nichts mehr ändern, also bräuchte man es auch nicht in JEDEM Build-Prozess. Trotzdem hatte ich öfters Fälle wo die im Debugger einfach IDE System-Files öffnet und ändert, und dann beim Schliessen fragt ob man das Speichern möchte. Wenn man dann im Eifer die falsche Taste "JA" drückt könnte man SystemFiles ungewollt ändern, und so Bugs reinbauen. Da hast Du dann Recht das diese Tests dann auch in jedem Build Sinn machen können. |
AW: Delphi-Unit-Tests project
Die Tests selber haben nix mit TestInsight zu tun. TestInsight ist nur ein Listener für die unterstützten TestFrameworks und hat Null mit den Tests an sich zu tun.
IMO ist hier ein bisschen Mitarbeit von Embarcadero wünschenswert - ich bin nämlich gar nicht sicher, wie deren Unittest/CI Setup aussieht und ob das DUnit(X) nutzt oder irgendwas selbstgetüfteltes - zumindest tauchten früher oft in den QC und QP Reports immer Snippets auf, die auf ein anderes Format hinwiesen. Wenn die nämlich nicht einfach die Tests nehmen können/wollen und sie in ihr CI kippen, dann ist das ganze Projekt witzlos. |
AW: Delphi-Unit-Tests project
Zitat:
Von Emba erwarte ich da nicht viel, weder dass die sich dran beteiligen, noch dass die das Nutzen werden. Wichtig wäre das für uns, genau aus obigem Grund. Damit die Entwickler selber Testen können wo etwas kracht, weil es Emba nicht macht. Das gute, alte DIY Prinzip :stupid: |
AW: Delphi-Unit-Tests project
Zitat:
Und wenn der Fix dann in einer Version ist, enttäuscht sein, dass man die wegen irgendnem neuen Bug nicht nutzen kann. Zitat:
|
AW: Delphi-Unit-Tests project
Zitat:
|
AW: Delphi-Unit-Tests project
Tja, die Schere zwischen Wunsch und Wirklichkeit klafft immer weiter auseinander.
Und auch bei dem Scherenvergleichs-Begriff kräuseln sich mir mittlerweile die Fußnägel 2m hoch. :stupid: DIY ist schonmal besser als nichts, aber Ihr habt natürlich vollkommen Recht. Immerhin bezahlen wir auch ein paar Penunzen für den ganzen Spaß. Vielleicht sollte Emba doch mal ein paar sinnvolle Interna als OpenSource rausstellen, damit die Entwicklung und Bugixes schneller vorangehen können. Das auch im Hinblick wenn ich mir aus anderen Threads Parnassus, ParallelDebugger, etc. ansehe. Da kommt Rx11 raus, und ich kann es 2 Monate nicht nutzen weil dies und das fehlt. Ja, ich habe mich damit mehr oder weniger arrangiert, aber immer wenn ich mal drüber nachdenke ... :evil: |
AW: Delphi-Unit-Tests project
Selbst wenn Embarcadero die Tests nicht selbst nutzen sollte (was ich für äußerst dämlich halten würde), können die diversen Early-Beta-Tester diese ja frühzeitig anwenden um Regressions auch zeitnah aufzuspüren.
|
AW: Delphi-Unit-Tests project
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:20 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz