![]() |
AW: Von 0 auf 100 - Delphi.Mocks ein Mockframework für Delphi
Zum Thema Ekon 14: selber schuld, dass du seitdem nicht mehr hingegangen bist?
Zu Spring: Stefan Glienke hat auch erzählt, dass V2.0 in einer Alpha Version schon von ein paar Leuten erfolgreich eingesetzt wird und das API sich nach seiner aktuellen Einschätzung wohl nicht mehr großartig ändern wird. Wenn ich seine Ekon Präsentation richtig verstanden habe, kann man damit Generics Code "Bloat" richtig gut eindämmen. Aber auch ich muss mir Spring mal endlich anschauen... Grüße TurboMagic |
AW: Von 0 auf 100 - Delphi.Mocks ein Mockframework für Delphi
Zitat:
|
AW: Von 0 auf 100 - Delphi.Mocks ein Mockframework für Delphi
Zitat:
|
AW: Von 0 auf 100 - Delphi.Mocks ein Mockframework für Delphi
Nur mal so als Teaser, warum Spring.Mocking besser ist als Delphi.Mocks. 8-)
Ich arbeite gerade, dass man das Mock Setup aus dem Video bei ca 21:00 so schreiben kann:
Delphi-Quellcode:
ml.Setup.Returns(True).When.TryGetOperation(Arg = 'm', Arg.Ref(mo.Instance).Return);
Syntax und Benamung für den Out Parameter Teil ist noch nicht final. |
AW: Von 0 auf 100 - Delphi.Mocks ein Mockframework für Delphi
Die Mocks sind sehr interessant für die Entwicklung von neuen Klasse im Team, so setze ich das auch teilweise ein.
Mich würde aber mal interessieren ob man Mocks auch zum Erweitern von bestehenden, aktiven Klassen einsetzen sollte, also auch generell im produktiven Umfeld in echten Applikationen ? Ich denke es spricht nichts dagegen, aber es könnte auch sein das Mocks da an gewissen Stellen Probleme machen (Speicherbedarf, Timing, usw.). Wann sollte man das besser nicht produktiv nutzen, wenn überhaupt ? |
AW: Von 0 auf 100 - Delphi.Mocks ein Mockframework für Delphi
Zitat:
Was du vermutlich eher meinst, sind dynamische Proxies, die man hinter Interfaces schalten kann, und die vor der eigentlichen das Interface implementierenden Klasse noch Zusatzlogik ausführen, oder? |
AW: Von 0 auf 100 - Delphi.Mocks ein Mockframework für Delphi
Naja, ich meinte schon existierende Klassen etwas zu erweitern.
Es könnte dabei schon Sinn machen und diese Klassen dann eben mit noch nicht 100% ausprogrammierten Erweiterungen benutzt werden können. Es passiert ja schonmal das man eine alte Klasse um eine kleine Schnittstelle erweitern muss. Ich habe jetzt gerade auch kein tolles Beispiel, aber es kommen ja immer von aussen neue Anforderungen hinzu (zumindest ist das bei mir oft so). Vielleicht als Beispiel eine Erweiterung 1FA zu 2FA:
Delphi-Quellcode:
Ist vielleicht ein blödes Beispiel, im Moment fällt mir aber nichts Besseres ein.
//alte Klasse:
function CanGenerate_1FA_Token : String; // funktionert alles, wird produktiv eingesetzt function Generate_1FA_Token : String; // funktionert alles, wird produktiv eingesetzt //Erweiterung: function CanGenerate_2FA_Token : String; // gemocht, im RELEASE immer False function Generate_2FA_Token : String; // gemockt im Test, aus gegebenem Anlass, wird das erweitert Natürlich setzte ich mal voraus das beide Funktionen relativ unabhängig sein sollten, und sich deshalb nicht "beissen" dürfen. Dein Vorschlag würde ja unter Umständen ein ziemliches Redesign bedeuten, was vielleicht gar nicht immer nötig ist, also warum nicht in der Übergangsphase mocken ? Man kann natürlich auch die Erweiterung erst komplett fertigstellen, und danach erst freigeben, aber falls soetwas mal länger dauern sollte dachte ich (naiv wie ich bin), wäre das Mocken eventuell auch eine Option. Ich verstehe deine Antwort mal so das Mocks dafür eher nicht geeignet sind um während der Erweiterungsphase etwas dranzubauen. Rollo |
AW: Von 0 auf 100 - Delphi.Mocks ein Mockframework für Delphi
Zitat:
Dort kann man ja dann Dummy Verhalten einbauen - dafür braucht man keine Mocks, wie sie hier Thema sind. Mocks, wie sie hier thematisiert wurden sind dafür da, in Unit tests ebend nur genau das implementieren zu müssen, was die getestete Komponente benötigt. Dies ist in vielen Fällen ja pro Test nur ein Teil eines gegebenen Interfaces mit bestimmten Eingaben und ggf Ausgaben. Und dafür muss man dann das Interface nicht herkömmlich in einer Klasse implementieren. Etwas, was in Produktionscode schon gegeben ist, aber erweitert werden soll. Und selbst wenn es ein komplett neues Interface gibt, muss es irgendwann implementiert werden, somit wäre der Gebrauch eines Mocks hier auch unnötig. Wofür sich Mocks aber durchaus eignen, ist Prototyping - wenn ich nur bestimmte Teile ausprobieren möchte, aber diese durchaus noch weitere Komponenten benutzen, die ich im Prototyp gerade nicht benutzen möchte oder kann. Dann ersetzen die dort ähnlich wie in einem Unit- oder Integrationstest diese Teile. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:43 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-2025 by Thomas Breitkreuz