Reset JPA erzeugten Wert zwischen den tests

Ich bin mit spring + hibernate + JUnit mit springJunit4runner-und Transaktions-Standard-rollback-ich bin mit in-memory als Datenbank derbydb. Hibernate dient als JPA-Provider, und ich bin erfolgreich testen, CRUD-Arten von Sachen. Allerdings habe ich ein problem mit JPA und das Verhalten von @GeneratedValue

Wenn ich einem meiner tests in isolation, zwei entitys sind permanent mit der id 1 und 2. Wenn ich das ganze test-suite der ids statt 6 und 7. Der Frühling hat rollbacks nur gut, also es gibt nur diese zwei entitys in der Datenbank nach der Zugabe und natürlich null vor. Aber das Verhalten von @GeneratedValue erlaubt mir nicht, um zuverlässige findById, wenn ich zurückkehren würde, die Id aus der

dao.add(Entity e) //method

Ich keine Lust, dass aus Gründen der Erprobung, oder ist es eine gute übung, um die Rückkehr der Einheit wurde beibehalten, sodass ich sollte es tun, eh?

InformationsquelleAutor Rythmic | 2013-10-19

1

Ihre tests nicht wirklich abhängig von Ihren jeweiligen ID-Werte erzeugt werden.. - ID-Zuweisung ist die Datenbank & Persistenz-layer-Aufruf & nicht Ihre Verantwortung, um Annahmen über.

Nicht dao.add(Entity e) legen Sie die ID/primary key-Eigenschaft in der Entität? Normalerweise Hibernate setzt IDs vor dem speichern von Entitäten, für die generierten & sequence zugewiesen IDs zumindest.

(Übrigens, ich empfehle, mit einem tragbaren (Tabellen -) Zuweisung und nie je nach Datenbank-spezifische Zuweisungen Mechanismen-Sequenzen oder autoincrement-Spalten. Portable allocators arbeiten Sie schneller & abhängig von proprietären key-Belegung wird es sehr, sehr viel schwerer, jemals eine andere Datenbank.)

Im Allgemeinen Systeme, die Daten speichern tun müssen wissen, welche ID es gespeichert wurde.. sonst würde es keine zuverlässigen & einzigartige Mittel, das abrufen, das ist der ganze Grund, warum wir haben ein PK in den ersten Platz!

So könnten Sie auch herausfinden, wie es richtig an dieser Stelle.
- Ich habe Umgerechnet id-Generierung Tabelle basiert. Aber der Grund, warum der test wurde unter Berufung auf eine hart-codiert erwartet-Id war, da konnte ich nicht ergattern die id durch die Einheit, weil in der add(Entity e) Methode, die unter bestimmten Umständen eine Kopie der zur Verfügung gestellten Entität erstellt wurde und der anhaltenden Arbeit, die Kopie, damit die Id nicht aktualisiert, in das ursprüngliche Objekt. Es war ein wirklich dummes Konstrukt, also änderte ich das auch.
- Das klingt Super.. sollte dazu führen, viel mehr eine solide Basis für die zukünftige Entwicklung Ihrer app, und die immer robuster wird Ihr Leben viel einfacher auf lange Sicht.
InformationsquelleAutor Thomas W
0

Fand ich einen Weg, es zu tun. Manuell alter table-restart/reset der auto_increment-Wert. Wie benutze ich die Derby DB dies wird durch die folgende sql-Abfrage ausgegeben, als eine native Abfrage nennen, da ich-wie erwähnt-die Verwendung der JPA-API
```
em.createNativeQuery("ALTER TABLE konsult ALTER COLUMN id RESTART WITH 1").executeUpdate();
```
Es ist ziemlich selbsterklärend, aber im Grunde bieten Sie den Namen der Tabelle und dem auto-increment-Spalte der Tabelle und wählen dann, welchen Wert der ersten Zeile beibehalten werden sollte, gegeben.

Hier ist der Weg, es zu tun mit mysql:
Zurücksetzen auto-Inkrement-Wert der MySql-Datenbank mit JPA

Ich bin immer noch offen für andere Vorschläge, denn das ist sozusagen ein hack, und wird auf diese Weise die Abhängigkeit von anderen tests. Es ist auch nicht RDBMS-unabhängige.

InformationsquelleAutor Rythmic

in unserem Projekt verwenden wir spring boot und h2 in-memory db für test -, und wir lösten es mit der folgenden Anmerkung auf die Prüfungen Klassen:

@DirtiesContext(classMode = DirtiesContext.ClassMode.BEFORE_EACH_TEST_METHOD)

Beispiel:

    @RunWith(SpringRunner.class)
    @AutoConfigureMockMvc
    @SpringBootTest(
        webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT,
        classes = Main.class
    )
    @DirtiesContext(classMode = DirtiesContext.ClassMode.BEFORE_EACH_TEST_METHOD)
    @TestPropertySource(locations = "classpath:application-test.properties")
    public class FooTest {

    }

Vielen Dank, Sie haben gemerkt, diese Frage ist über 5 Jahre alt jetzt, also problem gelöst 🙂 Gut zu sehen, ein moderner Ansatz, aber.

InformationsquelleAutor GoldenSky

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.