Für den Zugriff auf Objekte wurde ein Slick-DAO erstellt, das Funktionen enthält, die Aktionen und Objekte eines gespeicherten Typs zurückgeben. Beispiel:
%Vor% Beachten Sie, dass die nicht auf Aktionen basierende Funktion die andere in db.run() umschließt.
Was ist ein solider Ansatz, um beide Funktionen zu testen und die Redundanz von Code zu minimieren?
I naive Methode könnte natürlich sein, sie beide mit ihren individuellen Test-Setups zu testen (oben ist ein einfaches Beispiel; es könnte eine Menge Test-Setup benötigt werden, um DB-Restriktionen zu erfüllen).
Beachten Sie, dass die nicht aktionsbasierte Funktion die andere in db.run () umschließt.
Nicht wirklich. Ihre findByKeys -Methode ruft nicht findByUserIdAction auf, also passe ich das kleine Detail in dieser Antwort an.
Der obige Code gibt DBIOAction zurück. Wie in der Dokumentation angegeben ist:
Genau wie eine Abfrage ist eine E / A-Aktion nur eine Beschreibung einer Operation. Das Erstellen oder Erstellen von Aktionen führt nichts in einer Datenbank aus.
Soweit es einen Benutzer von Slick betrifft, gibt es keinen sinnvollen Test für ein DBIOAction , weil er selbst nichts tut; es ist nur ein Rezept für das, was man machen möchte. Um das obige DBIOAction auszuführen, müssen Sie materialisieren , was das ist Folgendes tut:
Das materialisierte Ergebnis ist das, was Sie testen möchten. Eine Möglichkeit, dies zu tun, ist die Verwendung von ScalaTests ScalaFutures Merkmal. In einer Spezifikation, die diese Eigenschaft mischt, könnten Sie beispielsweise Folgendes haben:
Schauen Sie sich dieses Slick 3.2.0-Testprojekt für weitere Beispiele an: TestSpec und QueryCoffeesTest .
Zusammenfassend: Versuchen Sie nicht, einen DBIOAction isoliert zu testen; Testen Sie einfach sein materialisiertes Ergebnis.