Sollte ich JDBC-Verbindung beibehalten oder nicht?

Question

Für meine Integrationstests habe ich gemeinsame Validierungsklasse aufzubauen, die Methoden wie

public void countcheck(table1, table 2){ // makes a JDBC connection and run the query to check counts and then closes the connection }; 

public void nullcheck(Table, ColumnName) {// makes a JDBC connection and the run query to make sure there are no Nulls and then closes the connection); 

und so weiter hat. Ich verteile diese gängigen Validierungsmethoden als Jars für Integrationstester. Mein Dilemma ist, ob ich die Verbindung für jede Methode öffnen und schließen soll, ich möchte nicht, dass Tester sich Sorgen um das Öffnen und Schließen von Verbindungen machen und sich nur darum sorgen müssen, Validierungsmethoden aufzurufen. Ich suche nach alternativen Design oder das ist etwas gut genug. Meine Sorge ist, wenn es in einer Testsuite 10 Tests gibt, dann gäbe es 10 Verbindungen, die gehen und schließen, was vielleicht kein gutes Zeichen ist? Ich möchte, dass Tester sich Gedanken machen, ob sie Makig machen und Verbindungen schließen wollen. Es ist ein auf Junit basierendes Testframework und DB ist Oracle.

Answer 1

Sie sollten die Entscheidung über die Handhabung von DB-Verbindungen in Ihrem Code nicht "einbürgern". Stattdessen sollten Sie diese Entscheidung den Benutzern überlassen, die Ihr Framework bereitstellen.

Wenn sie beschließen, Verbindungen wieder zu verwenden, könnten sie configure connection pool dafür; Wenn sie beschließen, jedes Mal Verbindungen zu öffnen und zu schließen, könnten sie das Framework ohne Verbindungspooling konfigurieren.

Ihre Aufgabe besteht darin, ihnen die entsprechende Technologie zur Verfügung zu stellen.

Answer 2

Ich übergebe normalerweise DataSource in solche Objekte (Konstruktoren) und bekomme die Verbindung für jede Geschäftsmethode. Im Standalone-Modus bedeutet dies möglicherweise, dass kein richtiger Pool verwendet wird, aber wenn Sie nur eine Handvoll Anweisungen ausführen, ist das kein Problem.

In der Produktion können Sie dann in einem echten Pool übergeben. Der Vorteil des Beibehaltens einer Datenquelle im Gegensatz zu einer Verbindung besteht darin, dass dieses Szenario bessere Selbstheilungsfunktionen bietet und die Anzahl der aktiven Verbindungen verringert. (In Testszenarien ist dies möglicherweise nicht so wichtig, aber es gibt keine allgemein verwendbaren Validatoren).

Validator(DataSource ds) { 
    this.ds = ds; 
} 
validate(String val, ...) { 
    try (Connection c = ds.getConnection()) { 
     ... 
    } 
} 

Die meisten Fahrer haben eine native Datasource, aber Sie können auch eine genericone haben, die getConnection(), um return DriverManager.getConnection(url); implementiert. Es ist auch eine kleine Schnittstelle, die leicht zu spielen ist. Wenn Ihre Tests größer werden, verwenden Sie eine einfache Pooling-Datenquelle wie die von Apache Commons DBCP DriverAdapterCPDS.