Frage

Ich arbeite also an altem Code, der sich stark auf manuelle Datenbankoperationen konzentriert.Ich versuche, hier einen gewissen Anschein von Qualität aufrechtzuerhalten, also gehe ich so oft wie möglich auf TDD.

Der Code, an dem ich arbeite, muss ausgefüllt werden, sagen wir a List<Foo> von einem DataReader, der alle für ein funktionierendes Foo erforderlichen Felder zurückgibt.Wenn ich jedoch überprüfen möchte, ob der Code tatsächlich ein Listenelement pro Datenbankzeile zurückgibt, schreibe ich Testcode, der etwa so aussieht:

Expect.Call(reader.Read()).Return(true);
Expect.Call(reader["foo_id"]).Return((long) 1);
// ....
Expect.Call(reader.Read()).Return(true);
Expect.Call(reader["foo_id"]).Return((long) 2);
// ....
Expect.Call(reader.Read()).Return(false);

Das ist ziemlich mühsam und auch ziemlich leicht kaputt.

Wie sollte ich an dieses Problem herangehen, damit das Ergebnis nicht ein riesiges Durcheinander spröder Tests ist?

Übrigens verwende ich derzeit Rhino.Mocks dafür, aber ich kann es ändern, wenn das Ergebnis überzeugend genug ist.Solange die Alternative nicht TypeMock ist, denn deren EULA war für meinen Geschmack etwas zu gruselig, als ich das letzte Mal nachgeschaut habe.

Bearbeiten:Ich bin derzeit auch auf C# 2 beschränkt.

War es hilfreich?

Lösung

Um dies weniger mühsam zu gestalten, müssen Sie die Zuordnung zwischen dem DataReader und dem Objekt, das Sie in der Liste enthalten, kapseln/umgestalten.Es sind nur wenige Schritte erforderlich, um diese Logik zu kapseln.Wenn Sie diesen Weg einschlagen möchten, kann ich die Postleitzahl für Sie angeben.Ich bin mir nur nicht sicher, wie praktisch es wäre, den Code hier auf StackOverflow zu veröffentlichen, aber ich kann versuchen, ihn prägnant und auf den Punkt zu bringen.Andernfalls bleibt Ihnen die mühsame Aufgabe stecken, jede Erwartung an den Index-Accessor für den Leser zu wiederholen.Durch den Kapselungsprozess werden auch die Zeichenfolgen entfernt und diese Zeichenfolgen können in Ihren Tests besser wiederverwendet werden.

Außerdem bin ich mir derzeit nicht sicher, inwieweit Sie den vorhandenen Code testbarer machen möchten.Da es sich hierbei um Legacy-Code handelt, der nicht zum Testen entwickelt wurde.

Andere Tipps

Ich dachte darüber nach, etwas Code zu posten, und dann fiel mir der Nothin But .NET-Kurs von JP Boodhoo ein.Er hat ein Beispielprojekt dass er teilt und das während eines seiner Kurse erstellt wurde.Das Projekt wird gehostet auf Google-Code und es ist eine schöne Ressource.Ich bin mir sicher, dass es einige nützliche Tipps für Sie enthält und Ihnen Anregungen gibt, wie Sie das Mapping umgestalten können.Das gesamte Projekt wurde mit TDD erstellt.

Sie können die Foo-Instanzen in eine Liste einfügen und die Objekte mit dem vergleichen, was Sie gelesen haben:

var arrFoos = new Foos[]{...}; // what you expect
var expectedFoos = new List<Foo>(arrFoos); // make a list from the hardcoded array of expected Foos
var readerResult = ReadEntireList(reader); // read everything from reader and put in List<Foo>
Expect.ContainSameFoos(expectedFoos, readerResult); // compare the two lists

Kokos,

Da stimmt ein paar Dinge nicht.Erstens bedeutet dies, dass ich zuerst die Foos konstruieren und dann ihre Werte dem Mock-Reader zuführen muss, der nichts bewirkt reduzieren die Menge an Code, die ich schreibe.Zweitens: Wenn die Werte den Leser durchlaufen, werden die Foos nicht angezeigt Dasselbe Foos (Referenzgleichheit).Sie könnten sein gleich, aber selbst das setzt zu viel von der Foo-Klasse voraus, als dass ich mich an dieser Stelle nicht traue, darauf einzugehen.

Nur zur Verdeutlichung: Möchten Sie testen, ob Ihr Aufruf in SQL Server einige Daten zurückgegeben hat, oder ob Sie, wenn Sie einige Daten hätten, diese wieder dem Modell zuordnen könnten?

Wenn Sie Ihren Aufruf in SQL testen möchten, wurden einige Daten zurückgegeben, die meine Antwort gefunden hat Hier

@Rennen:Was ich teste, ist die programmgesteuerte Zuordnung der von der Datenbank zurückgegebenen Daten zum Anführungszeichen-Unquote-Domänenmodell.Daher möchte ich die Datenbankverbindung verspotten.Für die andere Art von Test würde ich einen umfassenden Integrationstest durchführen.

@Tal:Ich schätze, da hast du es ziemlich gut hinbekommen, und ich hatte Angst, dass das der Fall sein könnte.Wenn Sie Hinweise auf Artikel oder ähnliches haben, in denen jemand die Drecksarbeit erledigt und sie in leichter verständliche Schritte zerlegt hat, wäre ich Ihnen dankbar.Codebeispiele würden auch nicht schaden.Ich habe zwar eine Ahnung, wie ich dieses Problem angehen soll, aber bevor ich mich tatsächlich dazu traue, muss ich noch andere Dinge erledigen, und wenn das Testen mühsames Spotten erfordert, dann werde ich das tun.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top