AccUnit und Datenbanken (MSSQL, Jet & Co.)

[Josef Pötzl]

Hallo!

Ich bin gerade dabei, Tests für meine Datenzugriffsklassen zum MSSQL-Server aufzubereiten.

Problemstellung: Wie testet man, ohne die Test-DB durch die Tests dauerhaft zu verändern.

Ich mache das derzeit wie bei Tests mit Access-Datenbanken, dass ich mir an einer Stelle eine Vorlage (mdf + ldf) bereitstelle, diese Vorlage in ein Verzeichnis kopiere und dann die DB per sp_attach_db anhänge. Nach dem Test wird die DB wieder abgehängt und gelöscht, damit später wie die Vorlage kopiert werden kann.

Diesen Vorgang (oder einen besseren - falls ihr einen besseren Weg kennt) würde ich gerne direkt in AccUnit bereitstellen, da das lästiger Code in meiner Anwendung ist.

Wie könntest ihr auch so einen Funktionsaufruf aus AccUnit vorstellen?

Ich dachte an folgendes:

Code: Alles auswählen

'AccUnit:Database.Init("MSSQL", "Server", "DatabaseName1", "OriginalDateiDieKopiertWird", "Zielverzeichnis")
'AccUnit:Database.Init("JET", "", "DatabaseName2", "OriginalDateiDieKopiertWird", "Zielverzeichnis")

Public Sub Setup()

   TestManager.Database.AttachDatabases
   ' oder
   TestManager.Database.AttachDatabase("DatabaseName1")
   ' oder
   ' ? ? ?

End Sub

Public Sub Teardown()
   TestManager.Database.Detach
End Sub

Was meint ihr?


Anm.: Der Weg über Transaktionen funktioniert meiner Ansicht nach nur bei einfachen Tests, wo man prüfen will, dass das Schreiben funktioniert. Allerdings wird bei Jet dann auch der Autowert hochgezählt, wenn man ein Rollback durchführt. => Test-DB entspricht nicht mehr dem Original.

LG
Josef

[KGunder]

Hallo Josef,

meine Test sehen im Augenblick so aus:

Code: Alles auswählen


Public Sub Setup()
  ' ....
End Sub

Public Sub StartTest()
  DB.ADO.Execute "BEGIN TRANSACTION"
End Sub

Public Sub Test1.....()
End Sub

Public Sub StopTest()
  DB.ADO.Execute "ROLLBACK"
End Sub
 

D.h. ich bette den ganzen Test in eine Transaktion ein. Ein Problem mit den Autowerten sehe ich nun wirklich nicht.
Ich führe gerne meine Tests "praxisnah" durch. Mir wurde zwar schon mehrfach gesagt, ich sollte "künstliche" Testdaten nehmen, aber ich führe meine Tests gerne gegen "Realdaten" durch und dazu gehört auch mal, daß sich der Autowert ändert...

Viele Grüße

Klaus

[Paul Rohorzka]

Hallo Josef!

Ich würde es am schönsten finden, wenn das Standardszenario per Attribut auf Klassenebene angegeben werden kann. Als Angaben sollte dazu der ConnectionString und der Name von mdf/ldf reichen. Damit ließe sich wahrscheinlich ein Großteil der Szenarien abdecken.

Vorschlag für das Attribut:

Code: Alles auswählen


' AccUnit:AutoAttachDatabaseFile("server=...", "D:\Data\MyDb.mdf", "D:\Logs\MyDb_log.ldf")


Die Attribute habe ich nur geschätzt.

LG,
P

[Christoph Jüngling]

Anm.: Der Weg über Transaktionen funktioniert meiner Ansicht nach nur bei einfachen Tests, wo man prüfen will, dass das Schreiben funktioniert. Allerdings wird bei Jet dann auch der Autowert hochgezählt, wenn man ein Rollback durchführt. => Test-DB entspricht nicht mehr dem Original

Geht das Feld mit dem Autowert denn in irgendeiner Form in den Test ein? Wenn ja, hätte ich Zweifel, ob das ein sinnvoller Test ist. Wenn nicht, spielt es keine Rolle.

[Josef Pötzl]

Hallo!

@Paul:
Die Parameter werden vermutlich ähnlich bei bei meinem Beispiel sein. Ich würde das DMBS angeben, damit man bei Bedarf unterschiedliche Klassen verwenden kann. Bei Jet reicht das Kopieren der Datei aus, bei MSSQL ist nebem dem Kopieren auch Attach/Detach notwendig. Falls Oracle usw. verwendet werden soll, sehen die SQL-Anweisungen vielleicht wieder anders aus. Ich dachte an eine Schnittstelle für VErbidnung zw. diesen DBMS-Klassen und AccUnit-Steuerung. Je nach DBMS-Kennung im AccUnit-Attribut wird dann die passende Klasseninstanz (vielleicht sogar dll, damit nachträglich erweitert werden kann) geladen.
Statt dem Connectionstring würde ich einfach nur die notwendigen Kennungen (DBMS-System, DB-Name, anzuhöngende Dateien) im AccUnit-Atrribut angeben, dann muss sich der Tester keine Gedanken machen, ob er OLEDB, ODBC oder sonstige Connection-Strings angeben soll.

@Klaus:
Wenn du den Test innerhalb einer Transaction laufen lässt, hattest du schon einmal Probleme, wenn während dem Test weitere Transaktionen gestartet werden?


Das mit dem Autowert war nur ein Beispiel. Mir geht es grundsätzlich darum, dass man trotz Transaktion und Rollback die Test-DB verändert. Ich will aber bei Tests sicher sein können, dass ich immer das identische Ausgangsszenario habe - egal wie schlecht ich den Test schreibe. Vielleicht macht es an bestimmten Szenarien auch Sinn einen bestimmten Autowert abzufragen.
Anm. : Beim Autowert könnte man notfalls auch den Zähler per DDL zurückstellen - darum geht es mir aber jetzt gar nicht.

Alles innerhalb eine Transaktion laufen lassen wäre natürlich das einfachste. Aber kann man dann auch alle Funktionalitäten testen? Bei Jet sind doch die Daten, welche innerhalb einer Transaktion geschrieben werden, für andere Zugriffsarten noch gar nicht verfügbar, oder?

Außerdem habe ich die Befürchtung, dass so eine Transaktion nicht mehr das Original-Verhalten wiederspiegelt. Wir testen dann möglicherweise etwas, was im Realbetrieb gar nicht auftritt.




mfg
Josef

[Christoph Jüngling]

Auf jeden Fall nehme ich mir die Möglichkeit, Transaktionen in meiner Applikation zu verwenden, zumindest wenn das verwendete DBMS keine verschachtelten Transaktionen unterstützt.

[Paul Rohorzka]

Hallo!

Ich sehe die Sache mit dem Rollback-Attribut pragmatisch:
Dort, wo Transaktionen ausreichen und ich mit den Einschränkungen kein Problem habe, verwende ich diese Variante weil sie wunderbar einfach funktioniert. Ich gehe davon aus, dass es für einen Gutteil von Szenarien ausreichend ist. Die Randbedingungen sind dokumentiert (http://de.accunit.access-codelib.net/AccUnit-Attribute) und jeder kann für seinen Test entscheiden ob sie ein Problem darstellen.

Bezüglich der Frage der sauberen Testdatenbank wäre es vielleicht sinnvoll die Parameter zur Konfiguration über einen AccUnit-Dialog einstellen zu können. Denn wenn wir bedenken, dass auch Benutzername/Kennwort noch angegeben werden können müssen, ist das schon eine ganze recht unlesbare Menge für ein Attribut (die wir außerdem vielleicht auch gar nicht einfach so im Quelltext jedem auf's Aug drücken wollen). Außerdem ist das recht viel Information die für das Verständnis des Tests kaum von Interesse sein wird. Nicht zuletzt erwarte ich für die unterschiedlichen Datenbanksystem noch die eine oder andere Feinheit, die vielleicht im Laufe der Zeit noch konfiguriert werden muss. In diesem Dialog könnte man (in einer weiteren Ausbaustufe) auch mehrere Konfigurationen ablegen, die man im Attribut dann einfach mit einem Namen ansprechen könnte.

Was denkt ihr?

LG,
P

[Josef Pötzl]

Hallo!

Das mit dem Benutzerdialog für die Parameter finde ich gut. Das erspart das eine IntelliSense-Variante, um die passenden Parameter eingeben zu können.

Macht es Sinn, wenn man dann von AccUnit die passenden Connection-Strings (ODBC und OLEDB) oder die passenden Database- bzw. Connection-Instanzen erhält?

Ausbau des Parameterdialogs: Zu verknüpfende Tabellen angeben, damit AccUnit auch diese Aufgabe übernimmt, falls die Tests per DAO auf verknüpfte Tabellen zugreifen.

mfg
Josef