Hallo,
ich schreibe seit ein paar Monaten ASP.NET MVC 2 bzw. 3 Anwendungen und arbeite mich zur Zeit in die testgetriebene Entwicklung mithilfe von TDD ein.
Mir leuchtet ein, dass ein FakeRepository
geschrieben wird, damit die Unit Tests (aus verständlichen Gründen: Geschwindigkeit, Datenbank-Setup, ...) nicht gegen eine reale Datenbank ausgeführt werden. Mit dem FakeRepository
kann dann ein entsprechender Controller getestet werden, der per Constructor Dependency Injection ein bestimmtes IRepository
vom Typ FakeRepository
injiziert bekommt. Soweit verständlich.
Was ich allerdings noch nicht verstanden habe:1.Welchen Nutzen hat das FakeRepository
über die Möglichkeit, den zugehörigen Controller zu testen, hinaus?
1.Wie wird das echte Repository getestet, ohne Dummy-Daten in der Produktionsdatenbank zu persistieren?
m0rius
Mein Blog: blog.mariusschulz.com
Hochwertige Malerarbeiten in Magdeburg und Umgebung: M'Decor, Ihr Maler für Magdeburg
Hallo,
was genau willst du denn an dem Repository testen, wenn nicht die funktionalität? (Ich meine, wenn du dein DB Repository testen willst, wäre es ja nicht sinnvoll, die DB aussen vor zulassen).
mfg
serial
Das FakeRepository hat keinen weiteren nutzen als eben für die Tests das echte Repository zu faken.
Wenn du das echte Repository Testen willst, musst du dir schon dann eine TestDB heranziehen.
~~Hallo serial,
das ist ja eben meine Frage: Wie teste ich mein reales Repository? Lasse ich einmalig meine Unit Tests auf dem echten Repository durchführen und lösche danach – per Hand? – die Dummy-Daten, die beispielsweise beim Testen der Add()
-Funktion angelegt wurden?
Welchen Sinn macht es bzw. welchen Vorteil bringt es, durch Tests sicherzustellen, dass ich ein funktionierendes FakeRepository
habe? Das sagt ja noch nichts über die Funktionsfähigkeit meines realen Repositories aus!~~
Hallo FZelle,
vielen Dank!
m0rius
Mein Blog: blog.mariusschulz.com
Hochwertige Malerarbeiten in Magdeburg und Umgebung: M'Decor, Ihr Maler für Magdeburg
Ich teste meine Repositories so, dass ich wenn nötig per primitiven SQL Script Daten in der DB vorbereite, dann die Repository Methoden ausführe und nachher wieder mit custom-SQL Script prüfe ob in der Datenbank das erwartete drinnen steht. Und das ganze lasse ich in einer Transaction laufen, die am Ende zurückgerollt wird.
Lg XXX