web-dev-qa-db-de.com

Wie simuliert man eine DB zum Testen (Java)?

Ich programmiere in Java und meine Anwendungen machen viel Gebrauch von DB. Daher ist es mir wichtig, meine DB-Nutzung einfach testen zu können.
Worum geht es bei DB-Tests? Für mich sollten sie zwei einfache Anforderungen erfüllen: 

  1. Überprüfen Sie die SQL-Syntax.
  2. Noch wichtiger ist, überprüfen Sie, ob die Daten gemäß einer bestimmten Situation richtig ausgewählt/aktualisiert/eingefügt wurden. 

Nun, es scheint, dass alles, was ich brauche, eine Datenbank ist.
Aber eigentlich ziehe ich es nicht vor, da es schwierig ist, eine DB für einen Test zu verwenden: 

  • "Hol dir einfach eine Test-Datenbank, wie schwer könnte es sein?" - Nun, an meinem Arbeitsplatz ist es unmöglich, eine persönliche Test-Datenbank zu haben. Sie müssen eine "öffentliche" Datenbank verwenden, auf die jeder zugreifen kann.
  • "Diese Tests sind sicher nicht schnell ..." - DB-Tests sind normalerweise langsamer als gewöhnliche Tests. Es ist wirklich nicht ideal, langsame Tests durchzuführen.
  • "Dieses Programm sollte jeden Fall behandeln!" - Es wird etwas nervig und sogar unmöglich, jeden einzelnen Fall in einer DB zu simulieren. Für jeden Fall sollte eine bestimmte Anzahl von Einfüge-/Aktualisierungsabfragen erstellt werden, was ärgerlich ist und Zeit kostet.
  • "Warten Sie eine Sekunde, woher wissen Sie, dass es 542 Zeilen in dieser Tabelle gibt?" - Eines der Hauptprinzipien beim Testen ist, die Funktionalität auf eine andere Art und Weise testen zu können, als der getestete Code. Wenn Sie eine DB verwenden, gibt es normalerweise eine Möglichkeit, etwas zu tun. Daher ist der Test genau derselbe wie der Core-Code.

Sie können also herausfinden, dass ich DBs nicht mag, wenn es um Tests geht (natürlich muss ich das irgendwann tun, aber ich möchte später zu meinen Tests kommen, nachdem ich die meisten Fehler gefunden habe Rest der Testmethoden). Aber was suche ich? 

Ich suche nach einer Möglichkeit, eine DB, eine Mock-DB, das Dateisystem oder nur virtuellen Speicher zu simulieren. Ich dachte, dass es vielleicht ein Java-ToolPaket gibt, mit dem einfach (mithilfe der Codeschnittstelle) ein DB-Mock pro Test, mit simulierten Tabellen und Zeilen, mit SQL-Überprüfung und mit einer Codeschnittstelle zum Überwachen des Status (statt mit SQL) erstellt werden kann ). 

Kennen Sie dieses Werkzeug?


/ - Edit: Danke für die Antworten! Ich habe zwar nach einem Tool gefragt, aber Sie haben mir auch ein paar Tipps zum Problem gegeben. :) Ich werde einige Zeit brauchen, um Ihre Angebote zu prüfen, daher kann ich jetzt nicht sagen, ob Ihre Antworten nicht zufriedenstellend waren.

Wie dem auch sei, hier ist ein besserer Blick auf das, wonach ich suche - Stellen Sie sich eine Klasse namens DBMonitor vor, bei der eines der Features die Anzahl der Zeilen in einer Tabelle ermittelt. Hier ist ein imaginärer Code, wie ich diese Funktion mit JUnit testen möchte:

public class TestDBMonitor extends TestCase {

    @Override
    public void setUp() throws Exception {

       MockConnection connection = new MockConnection();

       this.tableName = "table1";
       MockTable table = new MockTable(tableName);

       String columnName = "column1";
       ColumnType columnType = ColumnType.NUMBER;
       int columnSize = 50;
       MockColumn column = new MockColumn(columnName, columnType, columnSize);
       table.addColumn(column);

       for (int i = 0; i < 20; i++) {
           HashMap<MockColumn, Object> fields = new HashMap<MockColumn, Object>();
           fields.put(column, i);
           table.addRow(fields);
       }

       this.connection = connection;
    }

    @Test
    public void testGatherStatistics() throws Exception {

       DBMonitor monitor = new DBMonitor(connection);
       monitor.gatherStatistics();
       assertEquals(((MockConnection) connection).getNumberOfRows(tableName),
                    monitor.getNumberOfRows(tableName));
    }

    String tableName;
    Connection connection;
}

Ich hoffe, dieser Code ist klar genug, um meine Idee zu verstehen (entschuldigen Sie mich für Syntaxfehler, ich habe manuell ohne mein liebes Eclipse: P eingegeben). 

Übrigens benutze ich ORM teilweise, und meine rohen SQL-Abfragen sind recht einfach und sollten sich von Plattform zu Plattform nicht unterscheiden. 

59
Eyal Roth

neue Antwort auf die alte Frage (aber die Dinge sind ein bisschen vorgerückt):

Wie simuliert man eine DB zum Testen (Java)?

sie simulieren es nicht. Sie verspotten Ihre Repositorien und Sie testen sie nicht oder Sie verwenden die gleiche Datenbank in Ihren Tests und Sie testen Ihre SQL. Alle In-Memory-Dbs sind nicht vollständig kompatibel, sodass Sie nicht die volle Abdeckung und Zuverlässigkeit erhalten. Versuchen Sie niemals, die tiefen Datenbankobjekte wie Verbindung, Ergebnismenge usw. zu simulieren/zu simulieren. Es gibt Ihnen keinerlei Wert und ist ein Alptraum, der entwickelt und gewartet werden muss

eine persönliche Test-Datenbank zu haben ist ziemlich unmöglich. Sie müssen eine "öffentliche" Datenbank verwenden, auf die jeder zugreifen kann

leider verwenden viele Unternehmen dieses Modell immer noch, aber jetzt haben wir docker und es gibt Bilder für fast jede DB. Kommerzielle Produkte haben einige Einschränkungen (wie bis zu wenige GB Daten), die für Tests nicht wichtig sind. Außerdem müssen Sie Ihr Schema und Ihre Struktur auf dieser lokalen Datenbank erstellen

"Diese Tests sind sicher nicht schnell ..." - DB-Tests sind normalerweise langsamer als gewöhnliche Tests. Es ist wirklich nicht ideal, langsame Tests durchzuführen.

ja, db-tests sind langsamer, aber sie sind nicht so langsam. Ich habe einige einfache Messungen gemacht und ein typischer Test dauerte 5-50ms. Was Zeit braucht, ist der Start der Anwendung. Es gibt viele Möglichkeiten, dies zu beschleunigen:

  • erste DI-Frameworks (wie der Frühling) bieten nur einen Teil Ihrer Anwendung. Wenn Sie Ihre Anwendung mit einer guten Trennung zwischen db- und nicht-db-bezogener Logik schreiben, können Sie in Ihrem Test nur den Db-Teil starten
  • jede Db hat viele Einstellmöglichkeiten, wodurch sie weniger haltbar und viel schneller ist. das ist perfekt zum testen. postgres Beispiel
  • sie können auch die gesamte Datenbank in tmpfs einfügen

  • eine weitere hilfreiche Strategie besteht darin, Testgruppen zu haben und DB-Tests standardmäßig deaktiviert zu lassen (wenn sie den Build wirklich verlangsamen). Auf diese Weise muss jemand, der tatsächlich an db arbeitet, ein zusätzliches Flag in der cmd-Zeile übergeben oder IDE verwenden.

Für jeden Fall sollte eine bestimmte Anzahl von Einfüge-/Aktualisierungsabfragen erstellt werden, was ärgerlich ist und Zeit kostet

Der Teil "Zeit nimmt" wurde oben besprochen. ist das nervig? Ich habe zwei Möglichkeiten gesehen:

  • bereiten Sie einen Datensatz für alle Testfälle vor. dann muss man es aufrechterhalten und darüber nachdenken. Normalerweise ist es vom Code getrennt. Es hat Kilobytes oder Megabytes. Es ist zu groß, um auf einem Bildschirm zu sehen, zu verstehen und darüber nachzudenken. Es führt eine Kopplung zwischen Tests ein. Wenn Sie mehr Zeilen für Test A benötigen, schlägt Ihre count(*) in Test B fehl. Sie wächst nur, weil Sie selbst beim Löschen einiger Tests nicht wissen, welche Zeilen nur von diesem einen Test verwendet wurden
  • jeder Test bereitet seine Daten auf. Auf diese Weise ist jeder Test völlig unabhängig, lesbar und leicht zu verstehen. ist das nervig? Imo überhaupt nicht! Sie können sehr schnell neue Tests schreiben und sparen in der Zukunft viel Arbeit

woher wissen Sie, dass es in dieser Tabelle 542 Zeilen gibt? "- Eines der Hauptprinzipien beim Testen besteht darin, die Funktionalität auf eine andere Weise testen zu können als der getestete Code

ähm ... nicht wirklich. Das Hauptprinzip besteht darin, zu prüfen, ob Ihre Software die gewünschte Ausgabe als Reaktion auf eine bestimmte Eingabe erzeugt. Wenn Sie also dao.insert 542-mal aufrufen und Ihr dao.count dann 542 zurückgibt, bedeutet dies, dass Ihre Software wie angegeben arbeitet. Wenn Sie möchten, können Sie zwischenspeichern. Natürlich möchten Sie manchmal Ihre Implementierung anstelle des Vertrags testen und dann prüfen, ob Ihr Dao den Status der Datenbank geändert hat. Sie testen SQL A jedoch immer mit SQL B (Insert vs Select, Sequenz next_val vs. Rückgabewert usw.). Ja, Sie haben immer das Problem "Wer wird meine Tests testen" und die Antwort ist: Niemand, also halten Sie sie einfach!

andere Tools, die Ihnen helfen können:

  1. testcontainers hilft Ihnen bei der Bereitstellung von real db.

  2. dbunit - hilft Ihnen, die Daten zwischen den Tests zu säubern 

    nachteile: 

    • es ist viel Arbeit erforderlich, um Schema und Daten zu erstellen und zu verwalten. Besonders wenn sich Ihr Projekt in einer intensiven Entwicklungsphase befindet.
    • es handelt sich um eine weitere Abstraktionsebene. Wenn Sie also plötzlich ein Db-Feature verwenden möchten, das von diesem Tool nicht unterstützt wird, kann es schwierig sein, es zu testen
  3. testegration - beabsichtigt, Ihnen einen vollständigen, einsatzbereiten und erweiterbaren Lebenszyklus bereitzustellen (Offenlegung: Ich bin ein Schöpfer). 

    nachteile: 

    • kostenlos nur für kleine Projekte
    • sehr junges Projekt
  4. Flyway oder Liquibase - db Migrationstools. Sie helfen Ihnen bei der einfachen Erstellung eines Schemas und aller Strukturen auf Ihrer lokalen Datenbank für Tests.

12
piotrek

Java wird mit Java DB geliefert.

Das heißt, ich würde davon abraten, einen anderen DB-Typ zu verwenden, als Sie in der Produktion verwenden, wenn Sie nicht eine ORM-Schicht durchlaufen. Andernfalls ist Ihr SQL möglicherweise nicht so plattformübergreifend, wie Sie denken.

Check out DbUnit

40
ykaganovich

Ich habe Hypersonic für diesen Zweck verwendet. Im Grunde handelt es sich um eine JAR-Datei (eine reine Java-In-Memory-Datenbank), die Sie in einer eigenen JVM oder in Ihrer eigenen JVM ausführen können. Während sie ausgeführt wird, verfügen Sie über eine Datenbank. Dann stoppen Sie es und Ihre Datenbank verschwindet. Ich habe es bisher als reine In-Memory-Datenbank verwendet. Es ist sehr einfach, über Ant beim Start von Komponententests zu starten und zu stoppen.

10
Eddie

Es gibt viele Ansichten zum Testen von Integrationspunkten wie der Datenbankverbindung über SQL. Mein persönliches Regelwerk, das für mich gut funktioniert hat, lautet wie folgt:

1) Trennen Sie die Datenbankzugriffslogik und -funktionen von der allgemeinen Geschäftslogik und blenden Sie sie hinter einer Schnittstelle aus .. _ Grund: Um die große Mehrheit der Logik im System zu testen, verwenden Sie am besten einen Dummy/Stub die eigentliche Datenbank als einfachere . Grund 2: Sie ist erheblich schneller

2) Behandeln Sie Tests für die Datenbank als Integrationstests, die vom Hauptteil der Komponententests getrennt sind und in einer Setup-Datenbank ausgeführt werden müssen Grund: Geschwindigkeit und Qualität der Tests

3) Jeder Entwickler benötigt eine eigene Datenbank. Sie benötigen eine automatisierte Methode, um ihre Struktur basierend auf den Änderungen ihrer Teamkollegen zu aktualisieren und Daten einzuführen. Siehe Punkte 4 und 5.

4) Verwenden Sie ein Tool wie http://www.liquibase.org , um Upgrades in Ihrer Datenbankstruktur zu verwalten. __ Grund: Gibt Ihnen die Möglichkeit, die vorhandene Struktur zu ändern und in Versionen voranzukommen

5) Verwenden Sie ein Tool wie http://dbunit.sourceforge.net/ , um die Daten zu verwalten. Richten Sie Szenariodateien (xml oder XLS) für bestimmte Testfälle und Basisdaten ein und klären Sie nur ab, was für einen Testfall erforderlich ist . Grund: Viel besser als manuelles Einfügen und Löschen von Daten Grund 2: Einfacher für Tester sollen verstehen, wie man Szenarien anpasst. __ Grund 3: Es ist schneller, dies auszuführen

6) Sie benötigen Funktionstests, die auch DBUnit wie Szenariodaten haben. Dies sind jedoch weitaus größere Datensätze und führen das gesamte System aus. Damit ist der Schritt des Kombinierens des Wissens abgeschlossen, dass A) die Komponententests ausgeführt werden und die Logik daher solide ist B) dass die Integrationstests für die Datenbank ausgeführt werden und SQL korrekt ist "Und das System als Ganzes arbeitet der Stapel von oben nach unten "

Diese Kombination hat mir bisher gute Dienste geleistet, um eine hohe Test- und Produktqualität zu erreichen sowie die Geschwindigkeit der Entwicklung von Komponententests und die Agilität der Veränderung aufrechtzuerhalten.

10
Paul Keeble

"Hol dir einfach eine Test-Datenbank, wie schwer könnte es sein?" - Nun, an meinem Arbeitsplatz ist es unmöglich, eine persönliche Test-Datenbank zu haben. Sie müssen eine "öffentliche" Datenbank verwenden, auf die jeder zugreifen kann.

Klingt, als hätten Sie kulturelle Probleme bei der Arbeit, die ein Hindernis für Sie darstellen, um Ihre Arbeit so gut wie möglich zu machen und den Nutzen Ihres Produkts zu nutzen. Vielleicht möchten Sie etwas dagegen unternehmen.

Wenn sich Ihr Datenbankschema andererseits unter Versionskontrolle befindet, können Sie immer einen Testbuild erstellen, der eine Datenbank aus dem Schema erstellt, mit Testdaten auffüllt, Ihre Tests ausführt, die Ergebnisse sammelt und dann die Datenbank löscht. Es würde nur für die Dauer der Tests bestehen. Bei einer vorhandenen Installation kann es sich um eine neue Datenbank handeln, wenn Hardware ein Problem ist. Das ist ähnlich wie bei uns, wo ich arbeite.

6
banjollity

Wenn Sie Oracle bei der Arbeit verwenden, können Sie die Funktion Wiederherstellungspunkt in Flashback-Datenbank verwenden, um die Datenbank vor dem Test auf einen Zeitpunkt zurückzusetzen. Dadurch werden alle Änderungen entfernt, die Sie persönlich an der Datenbank vorgenommen haben.

Sehen:

https://docs.Oracle.com/cd/E11882_01/backup.112/e10642/flashdb.htm#BRADV71000

Wenn Sie eine Testdatenbank für Oracle Production/Work benötigen, suchen Sie die XE, Express Edition-Datenbank von Oracle. Dies ist kostenlos für den persönlichen Gebrauch, mit einer Datenbankbegrenzung von weniger als 2 GB.

4
Martlark

Wir haben kürzlich auf JavaDB oder Derby umgestellt, um dies zu implementieren. Derby 10.5.1.1 implementiert jetzt eine In-Memory-Darstellung, sodass es sehr schnell abläuft und nicht auf die Festplatte gehen muss: Derby In Memory Primer

Wir konzipieren unsere Anwendung für Oracle, PostgreSQL und Derby, damit wir auf keiner Plattform zu weit kommen, bevor wir herausfinden, dass eine Datenbank eine Funktion unterstützt, die andere nicht unterstützen.

3
Blair Zajac

Ich denke, mein Acolyte-Framework kann für solche DB-Modelle verwendet werden: https://github.com/cchantep/acolyte .

Es ermöglicht das Ausführen von vorhandenem Java (zum Testen) mit Verbindungen, für die die Abfrage-/Aktualisierungsbehandlung ausgeführt wird: Rückgabe entsprechender Resultsets, Aktualisieren der Anzahl oder Warnung nach Ausführungsfällen.

1
cchantep

Wir arbeiten gerade an einer Datenbank-Testumgebung. Wir glauben, dass wir ein real Datenbankmanagementsystem mit simulierten Daten verwenden müssen. Ein Problem bei einem simulierten DBMS ist, dass SQL als Standard nie wirklich gelistet ist. Eine künstliche Testumgebung müsste daher den Dialekt unserer Produktionsdatenbank treu unterstützen. Ein weiteres Problem besteht darin, dass wir die Spaltenwerteinschränkungen, Fremdschlüsseleinschränkungen und eindeutigen Einschränkungen ausgiebig nutzen. Da ein künstliches Werkzeug diese wahrscheinlich nicht implementieren würde, könnten unsere Komponententests bestehen, aber unsere Systemtests würden fehlschlagen, wenn sie das erste Mal die Realität treffen Einschränkungen. Wenn Tests zu lange dauern, deutet dies auf einen Implementierungsfehler hin und wir würden unsere Abfragen optimieren (normalerweise sind Testdatensätze im Vergleich zur Produktion winzig).

Wir haben ein echtes DBMS auf jedem Entwicklercomputer und auf unserem kontinuierlichen Integrations- und Testserver installiert (wir verwenden Hudson). Ich weiß nicht, was Ihre Einschränkungen für die Arbeitsrichtlinien sind, aber PostgreSQL, MySQL und Oracle XE lassen sich relativ einfach installieren und verwenden. Diese sind alle frei für die Entwicklung (auch für Oracle XE), daher gibt es keinen vernünftigen Grund, ihre Verwendung zu verbieten. 

Das Hauptproblem ist, wie Sie sicherstellen können, dass Ihre Tests immer mit der Datenbank in einem konsistenten Zustand beginnen. Wenn die Tests alle schreibgeschützt waren, kein Problem. Wenn Sie Mutationstests so erstellen könnten, dass sie immer in Transaktionen ausgeführt werden, die niemals festgeschrieben werden, ist dies kein Problem. In der Regel müssen Sie sich jedoch Gedanken machen, ob Updates zurückgenommen werden. Zu diesem Zweck können Sie den ursprünglichen Status in eine Datei exportieren und anschließend nach dem Test wieder importieren (dies geschieht mit Oracle-Befehlen exp und imp Shell). Oder Sie können einen Checkpoint/Rollback verwenden. Eine elegantere Methode ist jedoch die Verwendung eines Tools wie dbunit , das für uns gut funktioniert.

Der entscheidende Vorteil dabei ist, dass wir im Vorfeld viele weitere Fehler finden, deren Behebung viel einfacher ist und unser echter Systemtest nicht blockiert wird, während Entwickler fieberhaft versuchen, Probleme zu debuggen. Dies bedeutet, dass wir schneller und mit weniger Aufwand besseren Code produzieren.

1
Jim Ferrans

Verwenden Sie derby . Es ist einfach und tragbar. Mit Hibernate wird Ihre App flexibel. Testen Sie Ihr Derby, produzieren Sie alles, was Ihnen gefällt und vertrauen Sie.

1
Artic

Ich stimme der Banjollity zu. Die Einrichtung isolierter Entwicklungs- und Testumgebungen sollte hohe Priorität haben. Jedes Datenbanksystem, das ich verwende, ist entweder Open Source oder hat eine kostenlose Entwickleredition, die Sie auf Ihrer lokalen Workstation installieren können. Dadurch können Sie mit demselben Datenbank-Dialekt entwickeln wie die Produktion, Sie haben vollen Administratorzugriff auf Entwicklungsdatenbanken und sind schneller als mit einem Remote-Server. 

1
Nat

Sie könnten HSQLDB für Speicher-DB-Tests verwenden. Das Starten der Speicherdatenbank und das Durchführen von Tests sind ziemlich unkompliziert.
http://hsqldb.org/

1
Pratik Singhal

jOOQ ist ein Tool, das neben der SQL-Abstraktion auch kleine Tools wie SPI enthält, mit denen die gesamte JDBC-Version simuliert werden kann. Dies kann auf zwei Arten funktionieren, wie in diesem Blogbeitrag beschrieben :

Durch Implementieren des MockDataProvider-SPI:

// context contains the SQL string and bind variables, etc.
MockDataProvider provider = context -> {

    // This defines the update counts, result sets, etc.
    // depending on the context above.
    return new MockResult[] { ... }
};

In der obigen Implementierung können Sie jede SQL-Anweisung programmgesteuert abfangen und ein Ergebnis zurückgeben, sogar dynamisch, indem Sie den SQL-String "analysieren", um einige Prädikate/Tabelleninformationen usw. zu extrahieren.

Durch Verwendung der einfacheren (aber weniger leistungsfähigen) MockFileDatabase

... welches ein Format wie das folgende hat (eine Menge von Anweisungs-/Ergebnispaaren):

select first_name, last_name from actor;
> first_name last_name
> ---------- ---------
> GINA       DEGENERES
> WALTER     TORN     
> MARY       KEITEL   
@ rows: 3

Die obige Datei kann dann wie folgt gelesen und verwendet werden:

import static Java.lang.System.out;
import Java.sql.*;
import org.jooq.tools.jdbc.*;

public class Mocking {
    public static void main(String[] args) throws Exception {
        MockDataProvider db = new MockFileDatabase(
            Mocking.class.getResourceAsStream("/mocking.txt");

        try (Connection c = new MockConnection(db));
            Statement s = c.createStatement()) {

            out.println("Actors:");
            out.println("-------");
            try (ResultSet rs = s.executeQuery(
                "select first_name, last_name from actor")) {
                while (rs.next())
                    out.println(rs.getString(1) 
                        + " " + rs.getString(2));
            }
        }
    }
}

Beachten Sie, wie wir die JDBC-API direkt verwenden, ohne tatsächlich eine Verbindung zu einer Datenbank herzustellen.

Beachten Sie, ich arbeite für den Anbieter von jOOQ, daher ist diese Antwort voreingenommen.

Beachten Sie, dass Sie irgendwann eine komplette Datenbank implementieren

Das Obige funktioniert für einfache Fälle. Beachten Sie jedoch, dass Sie schließlich eine komplette Datenbank implementieren. Sie wollen:

  1. Überprüfen Sie die SQL-Syntax.

OK, indem Sie die Datenbank wie oben gezeigt verspotten, können Sie die Syntax "überprüfen", da jede Syntax, die Sie in der oben angegebenen Version von exact nicht vorgesehen haben, durch einen solchen Mocking-Ansatz abgelehnt wird.

Sie können einen Parser implementieren, der SQL analysiert ( oder wiederum jOOQs ) und dann die SQL-Anweisung in etwas umwandeln, für das Sie das Ergebnis leichter erkennen können. Im Endeffekt bedeutet dies jedoch nur die Implementierung einer gesamten Datenbank.

  1. Noch wichtiger ist, überprüfen Sie, ob die Daten gemäß einer bestimmten Situation richtig ausgewählt/aktualisiert/eingefügt wurden.

Das macht die Sache noch schwieriger. Wenn Sie eine Einfügung ausführen und dann aktualisieren, unterscheidet sich das Ergebnis offensichtlich von der Erstaktualisierung und dann der Einfügung, da sich die Aktualisierung möglicherweise auf die eingefügte Zeile auswirkt.

Wie stellen Sie sicher, dass dies geschieht, wenn Sie eine Datenbank "verspotten"? Sie benötigen eine Zustandsmaschine, die sich den Status jeder "verspotteten" Tabelle merkt. Sie implementieren also eine Datenbank.

Spott wird dich nur so weit bringen

Wie auch in piotrek erwähnt, werden Sie nur so weit gebracht. Dies ist in einfachen Fällen hilfreich, wenn Sie nur einige sehr bekannte Abfragen abfangen müssen. Es ist unmöglich, wenn Sie die Datenbank für ein gesamtes System simulieren möchten. Verwenden Sie in diesem Fall eine tatsächliche Datenbank, im Idealfall das gleiche Produkt, das Sie in der Produktion verwenden.

0
Lukas Eder

Zunächst einmal: Verwenden Sie ORM-Layer für den DB-Zugriff?
Wenn dies nicht der Fall ist, ist das, was Sie denken, von keinem Nutzen. Wenn Sie sich nicht sicher sind, ob SQL von Ihnen gestartet wird, werden Sie mit Ihrer Datenbank in der Produktion arbeiten. In Testfällen verwenden Sie etwas anderes
.__ Wenn ja: Dann können Sie sich verschiedene Optionen anzeigen lassen.

0
Khangharoth