Bestpractice : Test JPA Repositories

[8u3631984]

Hallo zusammen.
Ich zeige euch ersteinmal kurz meine KLassenstruktur :

@Builder(setterPrefix = "with")
@AllArgsConstructor
@NoArgsConstructor
@Getter
@Entity
@Table(name = "samsSeason", uniqueConstraints = @UniqueConstraint(columnNames = {"startYear", "endYear"}))
@ToString(callSuper = true)
public class Season extends DataEntity {

    @NonNull
    @JoinColumn(name = "startYear")
    private Integer startYear;

    @NonNull
    @JoinColumn(name = "endYear")
    private Integer endYear;
}

@Builder(setterPrefix = "with")
@AllArgsConstructor
@NoArgsConstructor
@Getter
@Entity
@Table(name = "samsCompetition", uniqueConstraints = @UniqueConstraint(columnNames = {"name", "season"}))
@ToString(callSuper = true)
public class Competition extends DataEntity {

    @NonNull
    @Column(name = "name")
    private String name;

    @NonNull
    @ManyToOne
    @JoinColumn(name = "season")
    private SamsSeason season;
}

@Repository
public interface CompetitionRepository extends JpaRepository<Competition, Long> {

    Optional<Competition> findByNameAndSamsSeason(String name, Season season);
}

@Repository
public interface SeasonRepository extends JpaRepository<Season, Long> {

    Optional<Season> findByStartYearAndEndYear(int startYear, int endYear);
}

So ich aheb also ein Season Klasse mit Repository und auch eine Competition Klasse. Meine Frage wenn ich nun das Competition repository testen möchte., z.B dass ein Competition Object richtig angelegt wird, so benötigte ich immer auch ein Season Object. Dieses muss vorher in der Datenbank auch angelegt werden.
Bisher habe ich mir eine TestUtils KLasse geschrieben, die mir solche Objekte erzeugt - also wirklich ind er Datenbank speichert. Meine Frage ist nun : Gibt es da eine elegantere Möglichkeit ?

 

[Oneixee5]

Braucht eine @Entity eigentlich nicht immer eine @Id!? https://www.baeldung.com/hibernate-identifiers
Du erstellst eine Entity-Klasse Season verwendest aber in Competition SamsSeason. Ich glaube es fehlt da noch etwas, was du hier aber nicht zeigst.

 

[thecain]

Braucht eine @Entity eigentlich nicht immer eine @Id!?

Das ist wahrscheinlich im DataEntity definiert

 

[8u3631984]

Ja genau dort bekommen die KLassen die ID

 

[8u3631984]

Braucht eine @Entity eigentlich nicht immer eine @Id!? https://www.baeldung.com/hibernate-identifiers
Du erstellst eine Entity-Klasse Season verwendest aber in Competition SamsSeason. Ich glaube es fehlt da noch etwas, was du hier aber nicht zeigst.

Du hast ein gutes Auge- das war ein Copy - Paste Fehler die Klassen heißen Season

 

[Oneixee5]

Möglicherweise suchst du das hier: https://www.baeldung.com/jpa-cascade-types. Ich weiß nicht ob das dein Problem komplett löst.

 

[thecain]

Ich weiss nicht ob ein Cascade die Lösung ist. Eventuell für den Test, aber für den UseCase wohl kaum. Wenn eine 1-n Beziehung zwischen Season und Competition besteht, muss eine Season existieren, damit eine Competition durchgeführt werden kann.

Das ist dann auch im Test so und mMn auch korrekt.

 

[JAVAKEK]

Was heißt hier "Competition repository testen"? Testest du wirklich lediglich, ob findByNameAndSamsSeason() ein korrektes Ergebnis liefert? Dann kannste auch gleich das restliche Spring Framework testen. Unabhängig von dem Sinn des Tests, sehe ich keinen Weg drumherum nicht die konkreten Objekte zu erzeugen.

Falls es dir darum geht, Business Logik zu testen, wo das Competition repository benutzt wird, kannst du natürlich das CompetitionRepository mocken und dir ein zusammengebautes Objekt zurückliefern, ohne irgendwas in die DB zu persistieren.

Vll. haust du mal deinen Testcase hier rein, dann sieht man wohl besser, was du da eigentlich abdecken willst.

 

[mrBrown]

Was heißt hier "Competition repository testen"? Testest du wirklich lediglich, ob findByNameAndSamsSeason() ein korrektes Ergebnis liefert? Dann kannste auch gleich das restliche Spring Framework testen. Unabhängig von dem Sinn des Tests [...]

Der Sinn dürfte Testen der Entitys ("sind Annotationen korrekt") und des Interfaces ("sind die Methoden und Parameter passend benannt") sein, das kann auch unabhängig von der restlichen Anwendung sinnvoll zu testen sein, grad um Fehler einzugrenzen.

 

[JAVAKEK]

Der Sinn dürfte Testen der Entitys ("sind Annotationen korrekt") und des Interfaces ("sind die Methoden und Parameter passend benannt") sein, das kann auch unabhängig von der restlichen Anwendung sinnvoll zu testen sein, grad um Fehler einzugrenzen.

Ich gebe dir Recht, dass hier Integrationstest bestimmt eine Rolle spielen können. Es kommt aus meiner Sicht auf die Komplexität der Anwendung an. Die Zeit für die Testerstellung, um ein einzelnes Repository zu testen, für das ich nicht mal eine Implementierung bereitstelle oder eigene wilde Queries definiert habe, (Spring startet nicht mal, wenn ich da einen groben Schnitzer in der Benennung habe) würde ich definitiv in ein paar Schichten weiter oben benutzen.