Integrationstests vs. Stored Procedures

Home » BI / SQL » Integrationstests vs. Stored Procedures – Teil 3

Integrationstests vs. Stored Procedures – Teil 3

22. April 2014

Am Anfang dieser Artikelserie wurde zunächst die Herausforderung aufgezeigt, die sich aus der durchgängigen Verwendung von Stored Procedures in Kombination mit umfangreichen Integrationstests ergibt. Im zweiten Teil der Artikelserie wurde dann gezeigt, wie sich der Zugriff auf Stored Procedures für CRUD-Operationen soweit abstrahieren lässt, dass man generische Methoden für eine beliebige Anzahl von Datenentitäten verwenden kann. Dadurch wird es auch möglich, für alle auf diese Weise aufrufbaren Stored Procedures die gleichen Integrationstests zu verwenden.

Doppelte Sicherheit

Für das Testen der Datenzugriffsmethoden bzw. der dahinterliegenden Stored Procedures sollten einige Voraussetzungen erfüllt sein:

Es wird eine Testdatenbank mit allen relevanten Tabellen und Stored Procedures benötigt. Empfehlenswert ist z. B. die Verwendung eines Datenbankprojektes, mit dem sich die Testdatenbank bequem aus Visual Studio heraus generieren lässt.
Man sollte für Testzwecke (und nur für diese) eine alternative Implementierung der Datenzugriffsmethoden haben, sodass man die tatsächlichen Datenzugriffsmethoden unabhängig voneinander testen kann.
Für jede Entität müssen bei dem im Folgenden vorgestellten Verfahren mindestens zwei Testdatensätze bereitgestellt werden. Eine Alternative hierzu wäre eine automatisierte Testdatengenerierung.

Des Weiteren wird ein geeignetes Test-Framework (z. B. das Visual Studio Testing Framework oder NUnit) benötigt. Zwar handelt es sich bei allen Tests nicht um autarke Unit-Tests, da sich die Stored Procedures nicht losgelöst von den Datenzugriffsmethoden testen lassen. Das Bestreben sollte aber dahin gehen, die Abhängigkeiten von weiteren Komponenten so gering wie möglich zu halten. Aus diesem Grund ist auch die angesprochene alternative Implementierung wichtig. Die im zweiten Teil der Artikelserie vorgestellten Hilfsmethoden für die Auswertung der Attribute können erneut zum Einsatz kommen, sollten dann aber idealerweise mit Unit Tests auf ihre Funktionstüchtigkeit getestet worden sein.

Es bietet sich an, für die alternativen Datenzugriffsmethoden konventionelle SQL-Statements zu verwenden. Da diese Methoden nur im Testprojekt bzw. auf der Testdatenbank verwendet werden, ist der Grundsatz, dass alle Datenbankzugriffe in der eigentlichen Anwendung per Stored Procedure zu erfolgen haben, davon nicht berührt.

Die alternative Implementierung der Datenzugriffsmethoden könnte so aussehen:

public IDataReader DirectSelect(Type type, int primaryKey)
{
    var tableName = GetTableName(type);
    var primaryKeyName = GetPrimaryKeyName(tableName);
  
    using (var connection = new SqlConnection("ConnectionString"))
    {
        connection.Open();
        var cmd = new SqlCommand("SELECT * FROM " + tableName + " WHERE " + primaryKeyName + " = " + primaryKey, connection);
        return cmd.ExecuteReader();
    }
}

public void DirectDelete(Type type, int primaryKey)
{
    var tableName = GetTableName(type);
    var primaryKeyName = GetPrimaryKeyName(tableName);
  
    using (var connection = new SqlConnection("ConnectionString"))
    {
        connection.Open();
        var cmd = new SqlCommand("DELETE FROM " + tableName + " WHERE " + primaryKeyName + " = " + primaryKey, connection);
        cmd.ExecuteNonQuery(); 
    }
}

public int DirectInsert(object item)
{
    var type = item.GetType();
    var tableName = GetTableName(type);
    var columnMappings = GetColumnMappings(type, false);
  
    var columnDict = new Dictionary<string, object>();
  
    foreach (var currentColumnMapping in columnMappings)
    {
        var property = currentColumnMapping.Key;
        var columnName = currentColumnMapping.Value;
        var rawValue = property.GetValue(item, null);
        var valueType = property.PropertyType;
        object finalValue;
  
        if (valueType == typeof(string))
        {
            finalValue = "'" + rawValue + "'";
        }
        else if (valueType == typeof(DateTime))
        {
            finalValue = string.Format("'{0:yyyy-MM-dd}'", rawValue);
        }
        else if ((valueType == typeof(int)) || (valueType == typeof(int?)))
        {
            if (rawValue == null) { continue; }
            finalValue = rawValue;
        }
        else if ((valueType == typeof(decimal)) || (valueType == typeof(decimal?)))
        {
            if (rawValue == null) { continue; }
            finalValue = ((decimal)rawValue).ToString(CultureInfo.InvariantCulture);
        }
        else if (valueType == typeof(bool))
        {
            finalValue = (bool)rawValue ? 1 : 0;
        }
        else
        {
            throw new InvalidOperationException("Unerwarteter Typ '" + valueType.Name + "' in Spalte '" + columnName + "'");   
        }
  
        columnDict.Add(columnName, finalValue);
    }
  
    var sql = string.Format("INSERT INTO {0} ({1}) VALUES ({2}); SELECT CAST(SCOPE_IDENTITY() AS INT)", tableName, string.Join(",", columnDict.Keys), string.Join(",", columnDict.Values));
  
    using (var connection = new SqlConnection("ConnectionString"))
    {
        connection.Open();
        var cmd = new SqlCommand(sql, connection);
        var identity = (int)cmd.ExecuteScalar();
        return identity > 0 ? identity : -1;   
    }            
}

Eine Doppelimplementierung der Datenzugriffsmethode für UPDATE-Operationen ist nicht zwingend erforderlich.

Blaupausen für die Integrationstests

Der Aufbau der einzelnen Integrationstests ist ähnlich, unterscheidet sich aber von CRUD-Operation zu CRUD-Operation, da jeweils etwas anderes getestet wird:

INSERT:

Datensatz in die Datenbank einfügen mit der zu testenden Methode
Datensatz aus der Datenbank auslesen mit der direkten Methode
Prüfen, ob die gelesenen Werte den geschriebenen Werten entsprechen
Datensatz aus der Datenbank löschen mit der direkten Methode

SELECT:

Datensatz mit der direkten Methode in die Datenbank einfügen
Datensatz aus der Datenbank auslesen mit der zu testenden Methode
Datensatz aus der Datenbank auslesen mit der direkten Methode
Prüfen, ob die gelesenen Werte in beiden Fällen identisch sind
Datensatz aus der Datenbank löschen mit der direkten Methode

UPDATE:

Datensatz mit der direkten Methode in die Datenbank einfügen
Den Datensatz in der Datenbank aktualisieren mit der zu testenden Methode
Datensatz aus der Datenbank auslesen mit der direkten Methode
Prüfen, ob die gelesenen Werte in beiden Fällen unterschiedlich sind
Datensatz aus der Datenbank löschen mit der direkten Methode

DELETE:

Datensatz in die Datenbank einfügen mit der direkten Methode
Datensatz mit der zu testenden Methode aus der Datenbank löschen
Prüfen, ob kein Datensatz mehr in der Datenbank ist mit der direkten Methode

Konkretes Beispiel

Im Folgenden soll das in diesem Abschnitt beschriebene Vorgehen exemplarisch anhand eines Tests für die im zweiten Teil der Artikelserie vorgestellte UPDATE-Datenzugriffsmethode gezeigt werden. In der Praxis braucht man natürlich auch für diese Methode mehr als einen Test. Denkbare wären z. B. Tests, die das Verhalten beim Hinzufügen doppelter Primary Keys prüfen usw.

Es wird davon ausgegangen, dass die Testklasse von einer Basis-Testklasse abgeleitet ist. In dieser Test-Basisklasse würden die Methoden DirectSelect, DirectDelete und DirectInsert implementiert sein. Weiterhin wird davon ausgegangen, dass sich die zu testenden Methoden sich in einer Klasse mit dem Namen DataAccess befinden.

Für diesen Test wird mit zwei Entitäten ein Vorher-/Nachher-Vergleich durchgeführt. Deswegen ist es notwendig, dass sich beide Entitäten in allen schreibbaren Werten mit Ausnahme des Primärschlüssels unterscheiden. In realen Projekten ist es sinnvoll, die Testdatengenerierung auszulagern oder zu automatisieren. Für das Beispiel ist es aber hinreichend, diese direkt zu instanziieren.

[Test]
public void AllProductPropertiesCanBeUpdated()
{
    var firstProduct = new Product { Name = "Some Product", InventoryNumber = 1 };
    var secondProduct = new Product { Name = "Another Product", InventoryNumber = 2 };
    
    DoUpdateTest(firstProduct, secondProduct);
}

In der Hilfsmethode DoUpdateTest() liegt die im Abschnitt “Blaupausen für die Integrationstests” beschriebene Prüflogik:

private void DoUpdateTest(object firstItem, object secondItem)
{
    var type = firstItem.GetType();
    var tableName = GetTableName(type); 
  
    // Sicherstellen, dass beide Entitäten unterschiedliche Werte haben
    var columnMappings = GetColumnMappings(type, false);
  
    var primaryKeyName = GetPrimaryKeyName(tableName);
    PropertyInfo primaryKeyProperty = null;
  
    foreach (var currentColumnMapping in columnMappings)
    {
        var property = currentColumnMapping.Key;
        var columnName = currentColumnMapping.Value;
  
        var firstValue = property.GetValue(firstItem, null);
        var secondValue = property.GetValue(secondItem, null);
  
        if (columnName == primaryKeyName)
        {
            // Primärschlüssel ermitteln
            primaryKeyProperty = property;
        }
        else if (firstValue == secondValue)
        {
            // Alle Properties bis auf den Primärschlüssel müssen unterschiedlich sein
            throw new InvalidOperationException("Die Eingangsdaten müssen unterschiedlich sein");
        }
    }
  
    if (primaryKeyProperty == null)
    {
        throw new InvalidOperationException("Der Primärschlüssel konnte nicht ermittelt werden");
    }
  
    var primaryKeyValue = 0;
  
    try
    {
        // Die erste Entität wird in die Datenbank geschrieben.
        primaryKeyValue = DirectInsert(firstItem);
  
        if (primaryKeyValue <= 0)
        {
            throw new InvalidOperationException("Der Primärschlüssel des erzeugten Datensatzes muss größer als 0 sein");
        }
  
        // Beide Objekte erhalten den Primärschlüssel des eingefügten Datensatzes.
        primaryKeyProperty.SetValue(firstItem, primaryKeyValue, null);
        primaryKeyProperty.SetValue(secondItem, primaryKeyValue, null);
  
        // Erzeugen der Testkomponente
        var dataAccess = new DataAccess();
  
        // Aufrufen der zu testenden Methode
        dataAccess.Update(secondItem);
  
        // Es gilt zu testen, ob alle schreibbaren Werte der ersten Entität durch
        // die Werte der zweiten Entität ersetzt wurden.
        using (var reader = DirectSelect(type, primaryKeyValue))
        {
            Assert.IsTrue(reader.Read());
  
            foreach (var currentColumnMapping in columnMappings)
            {
                var property = currentColumnMapping.Key;
                var columnName = currentColumnMapping.Value;
  
                var expectedValue = property.GetValue(secondItem, null);
                var actualValue = reader[columnName] != DBNull.Value ? reader[columnName] : null;
  
                // Alle ausgelesenen Werte müssen mit den Werten der zweiten Entität identisch
                // sein, die sich allesamt von den Werten der ersten Entität unterscheiden, was
                // zuvor geprüft wurde. Wenn das der Fall ist, wurden über die Stored Procedure
                // alle schreibbaren Werte ersetzt und der Test wird erfolgreich durchlaufen.
                Assert.AreEqual(expectedValue, actualValue);
            }
        }
    }
    finally
    {
        // Löschen, was sich löschen lässt.
        if (primaryKeyValue > 0)
        {  87:         }
            DirectDelete(type, primaryKeyValue);
    }
}

Wie man sieht, gibt es innerhalb der Methode DoUpdateTest() keinen direkten Bezug zu der Klasse Product. Alle benötigten Informationen lassen sich aus den zuvor festgelegten Namenskonventionen und den Metadaten, mit denen die Klasse angereichert wurde, ermitteln. Für weitere, nach dem gleichen Prinzip aufgebaute Klassen, kann daher die gesamte Testlogik einfach übernommen werden.

Normalerweise ist es nicht üblich, in einer Testmethode auch die Gültigkeit der Testdaten zu prüfen, wie es im obigen Beispiel gemacht wurde. In der Praxis haben sich solche Selbsttests aber als sehr nützlich erwiesen, da einer der häufigsten Fehler in der Bereitstellung unvollständiger Testdaten bestand. Dies passiert erfahrungsgemäß besonders oft beim Hinzufügen neuer Properties mit einem Default-Wert, also bei fast allen Properties, die hinzugefügt werden. In einer realen Anwendung kann es aber sinnvoll sein, die Selbsttests von den eigentlichen Testmethoden zu trennen.

Fazit

Der Vorgabe, Datenbankzugriffe grundsätzlich nur über Stored Procedures abzuwickeln, muss nicht im Widerspruch zu dem Anspruch, eine möglichst große Testabdeckung zu erzielen, stehen. Mit dem in dieser Artikelserie vorgestellten Weg lässt sich der Datenzugriff über die Stored Procedures so vereinheitlichen, dass man nicht mehr mit unzähligen, fragmentierten Tests zu kämpfen hat. Am besten ist, wenn man überhaupt nicht in die Verlegenheit kommt, in großem Stil Copy-and-Paste zu betreiben.

Da sich die Testlogik beliebig oft wiederverwenden lässt, lohnt es sich, diese zu verbessern. Die Erfahrung in der Praxis zeigt, dass durch Erweiterungen und Korrekturen der gemeinsam genutzten Testlogik nicht selten Fehler in bereits ausreichend getestet geglaubten Programmteilen finden.

Natürlich lässt sich auf diese Weise nicht jedes erdenkliche Szenario bewältigen. Insbesondere bei komplexen Abhängigkeiten zwischen den Entitäten und bei einer Verlagerung von erheblichen Teilen der Business-Logik in die Datenbank bzw. die Stored Procedures, stößt das Prinzip an seine Grenzen. Doch auch in solchen Anwendungen gibt es fast immer auch noch eine Vielzahl von klassischen Datenentitäten, für die sich die vorgestellte Methodik wiederum hervorragend eignet.