Welches Mock-Framwork?

[freimatz]

Hallo,
ich überlege gerade für ein weiteres Projekt Mocks einzusetzen. Was nehme ich da am Besten? Ich habe schon etwas geggogelt und da gibt es "Delphi Mocks", aber auch bei Spring4D, welches ich schon einsetze ist wohl was dabei.
(Ich verwende kein DUnitX, sondern das "normale" Framework.)

[Stevie]

Spring4D natürlich! 8-)

Ich bin da ja ein bisschen voreingenommen, aber ich behaupte, dass meine Implementierung fortgeschrittener ist, als die von Delphi-Mocks.

[freimatz]

:-D

Danke. Versuche es mal damit.

Habe hier auch ein Beispiel gefunden.

[Stevie]

Lass mir ruhig reichlich Feedback zukommen, gern auch per email.

[Der schöne Günther]

Kein Mensch der Welt kann ernsthaft etwas Schlechtes gegen Spring4D sagen.

Trotzdem, ich habe für meinen Teil nie verstanden wofür ich ein komplexes Mocking-Framework, meist mit elaboraten und wohlklingenden Fluent Interfaces, brauche. Ich komme mit dem

Delphi-Quellcode:

TVirtualMethodInterceptor

aus

Delphi-Quellcode:

System.Rtti

seit Jahren sehr schnell ans Ziel. Mir fehlt einfach die Phantasie was ein komplettes Framework hierfür mir bieten könnte, außer Dinge hinter wohlklingenden Abstraktionen zu verstecken in die man sich erst einarbeiten müsste.

tl;dr: Ich glaube nicht dass man für Mocking ein Mocking-Framework haben muss.

[Stevie]

Zitat:

Zitat von Der schöne Günther (Beitrag 1478082)

nie verstanden wofür ich ein komplexes Mocking-Framework brauche.

Vielleicht einfach deshalb, weil man ebend nicht händisch Callbacks für TVirtualInterface zusammen klöppeln möchte, wo man dann sein Behavior rein schreiben muss?

Delphi-Quellcode:

paymentServiceMock.Returns(success).When.Transfer(19.99, 'EUR')

im Unittest kann wohl kaum an Les- und Wartbarkeit überboten werden.

[freimatz]

Wozu man ein komplexes Mocking-Framework braucht, habe ich auch nie verstanden. Wozu ich aber ein einfaches Mocking-Framework will weiss ich ;-)

Leider ist Delphi immer noch so rückständig und bietet nichts "out of the box". Das liegt wiederum leider daran, dass gefühlt 99% der der Delphi-Entwickler^wProgrammierer keine Ahnung haben wozu man den Mocks überhaupt braucht. ("wir machen keine unit tests, dafür haben wir keine Zeit." :roll::wall:)

Darum umso mehr einen Riesen-Danke an Stevie für seinen Einsatz. :thumb:

Zurück zu meinem Thema:

Ich habe einen Klasse die auf GetShellFolderPath aufsetzt und da einiges tut. Der unit^wIntegrations-Test dazu war recht unstabil wenn andere Programm auch in %appdata% rummachen. Deswegen wollte ich diesen unteren Teil mit wegkapseln und mit einem Mocks testen. Das habe ich geschafft. Ziel erreicht. :)

Was ich vermisste war eine (für mich zu findende) Einführung in das Framework also z.B sowas. Einführungen die erst erklären wozu man DI und Mocks braucht finde ich eher suboptimal.

(In der Firma wo ich arbeite haben wir ein eigenes Framework. Dort werden allerdings die Mocks als Sourcecode von einem Tool erzeugt.)

[Stevie]

Zitat:

Zitat von freimatz (Beitrag 1478096)

Was ich vermisste war eine (für mich zu findende) Einführung in das Framework also z.B sowas.

https://bitbucket.org/sglienke/sprin...ts.Mocking.pas

[generic]

Ich finde für Delphi gibt es kein richtig schlechtes Framework!

Ich arbeite viel mit den Delphi.Mocks und daher gibt es ein Video/Tutorial im Youtube Kanal "Coding Bott" dazu.

https://www.youtube.com/watch?v=BjMW4VW1UgA

Wenn du bereits Spring4D drin hast, würde ich immer versuchen keine weiteren Libs aufnehmen.

[Stevie]

@Bernd: Das Beispiel in deinem Video bei 20:40 würde mit spring4d so ausschauen:

Delphi-Quellcode:

procedure Test;
var
  mo: Mock<IOperation>;
  ml: Mock<IOperationsListe>;
  op: IOperation;
begin
  mo.Setup.Returns(-1).When.Berechne(1, 2);
  ml.Setup.Returns(True).When.TryGetOperation(Arg = 'm', Arg.Ref(mo.Instance).Return);
  ml.Instance.TryGetOperation('m', op);
  Assert(op.Berechne(1, 2) = -1);
end;