Unit-Test-Methoden Mit Datei-IO
Ich versuche, in die Gewohnheit des Schreibens von unit tests, die ich geschrieben habe, ein paar zuvor, aber Sie haben meistens Recht einfach...ich möchte damit beginnen, einen Umzug zu TDD, wie ich will, zu verbessern die Qualität von meinem code (design und Struktur) - reduzierkupplungen, während zur gleichen Zeit hoffentlich reduzieren Sie die Anzahl der Regressionen, die rutschen durch, um eine überprüfbare bauen.
Habe ich ein relativ einfaches Projekt ich arbeiten, um mit zu beginnen. Das resultierende Programm überwacht einen Ordner und wirkt dann auf die Dateien in diesem Ordner.
Hier ist ein typisches Beispiel für code extrahiert aus dem Projekt:
private string RestoreExtension(String file)
{
var unknownFile = Path.GetFileName(file);
var ignoreDir = Path.GetDirectoryName(file) + "\\Unknown";
string newFile;
//We need this library for determining mime
if (CheckLibrary("urlmon.dll"))
{
AddLogLine("Attempting to restore file extension");
var mime = GetMimeType(BufferFile(file, 256));
var extension = FileExtensions.FindExtension(mime);
if (!String.IsNullOrEmpty(extension))
{
AddLogLine("Found extension: " + extension);
newFile = file + "." + extension;
File.Move(file, newFile);
return newFile;
}
}
else
{
AddLogLine("Unable to load urlmon.dll");
}
AddLogLine("Unable to restore file extension");
if (!Directory.Exists(ignoreDir))
{
Directory.CreateDirectory(ignoreDir);
}
var time = DateTime.Now;
const string format = "dd-MM-yyyy HH-mm-ss";
newFile = ignoreDir + "\\" + unknownFile + "-" + time.ToString(format);
File.Move(file, newFile);
return String.Empty;
}
Fragen :
Wie kann ich testen, eine Methode mit IO?
Ich nicht wirklich wollen, um mit einem echten Datei wäre langsam (und eher ein integration-test?), aber ich kann nicht wirklich sehen, einen anderen Weg. Ich könnte hinzufügen, eine schaltbare IO abstraction layer, doch das klingt für mich wie kann es unnötig verkomplizieren code...
Ist so ein Projekt lohnt sich unit-Tests?
Damit meine ich, ist es zu einfach. Sobald Sie den Streifen aus .Netto-und 3rd-party-Bibliothek fordert, da bleibt nicht viel übrig...So ist es ein Fall, dass die Menge an Arbeit, um es überprüfbar bedeutet, es ist nicht ein guter Kandidat, um zu testen?
Viele der Methoden in diesem Projekt sind private, wie dieses Projekt kommt zu einem windows-Dienst. Ich habe gelesen, Sie sollte eigentlich nur testen Methoden, die extern sichtbar (public oder ausgesetzt über eine Schnittstelle), ist es unwahrscheinlich, in diesem Fall jedoch, dass ich Belichten möchte alle meine eigenen Methoden. So ist dieses Projekt im Wert von testing (id-wahrscheinlich benötigen, um entweder zu ändern Methode zugriffsmodifizierer auf public oder fügen Sie einige Attribute, so dass NUnit Sie sehen kann)?
Cheers
InformationsquelleAutor rupertmulrenan | 2013-05-14
Du musst angemeldet sein, um einen Kommentar abzugeben.
Bezug auf, wie um zu testen, Datei-I/O:
Ein üblicher Weg, dies zu tun ist, Kapselung von Datei-I/O in eine wrapper-Klasse. Zum Beispiel:
In der Methode, unter test Sie nur das Programm auf die Schnittstelle. Beim ausführen der unit-Tests, die Sie verwenden würden, ein mock-Objekt liefert vordefinierte Werte. Für diese, die Sie nutzen könnten Moq.
Das ist ein bisschen Arbeit zu tun, aber dann brauchen Sie nicht zu testen, Datei-I/O sowie.
Besten
Jan
InformationsquelleAutor nein.
Durch die Einführung von Abstraktion über die .NET-IO-Bibliotheken und dann unter Verwendung der realen Umsetzung (BCL) in Anwendung, und gefälschten (verspottet), eine in der unit-test. Eine solche Abstraktion ist ziemlich einfach zu schreiben auf Ihre eigenen, aber jene Projekte, die bereits vorhanden sind (zB. System.IO.Abstraktion ), so dass Rad neu zu erfinden ist sinnlos, vor allem in solch triviale Angelegenheit.
Dies ist korrekt, im test, den Sie verwenden möchten fake (verspotten) Objekte.
Jedes Projekt ist es Wert testen und testen Sie es in die eine oder andere Weise (im extremsten Fall durch manuelles ausführen von Anwendungs-und tut das gute, alte click-and-wait testen).
Beachten Sie, dass fast immer ist es zu zeitaufwendig manuell zu testen 10 edge Fällen von komplexen parser-Methode, die jedesmal, wenn Sie benötigt zu große Datei laden und auf Ergebnisse warten. Dies ist, wo automatisierte tests in isolierten Umgebung sehr helfen. Es ist das gleiche mit Ihrem code - Datei-system, web-service, der Sie alle einführen, großer overhead, bevor man zum eigentlichen business-Logik. Isolieren müssen.
Wieder zu korrigieren, sollten Sie prüfen, öffentlicher Auftrag. Jedoch, wenn private Sachen bekommt groß genug, um es zu testen, die meisten der Zeit es ist ein guter Indikator ist auch groß genug, um es in seiner eigenen Klasse. Beachten Sie, dass das ändern der Mitglieder zugriffsmodifizierer nur für die unit-test-Nutzung ist nicht die beste Idee. Fast immer ist es besser, zu extrahieren-Klasse/Methode umgestalten.
InformationsquelleAutor k.m
Ich bin ziemlich neu mit TDD zu, aber ich denke, ich kann einige Vorschläge für Sie:
Über IO-Test. Sie können mock-Objekte. Erstellen Sie ein mock für die Methode, die Sie testen möchten, und vergleichen Sie es mit echten übergebenen Wert. In der Moq-Framework es so aussieht:
Absolut, ja. Wenn Sie wollen bekommen Sie eine Gewohnheit, die Sie benötigen, um alles zu testen, nehme ich an. Diese Weise Erkenntnis stammt 😉
Können Sie InternalsVisibleTo Attribut zu vermeiden, Sichtbarkeit Probleme.
Ich denke das man über enterprise Programmierung. nur spare Zeit mit Ihrer eigenen vertrauenswürdigen code.
Hoffe, meinen Standpunkt kann Ihnen helfen.
InformationsquelleAutor kirillta
Können Sie tun, dass die Verwendung Microsoft Fakes. Erste generieren Sie eine gefälschte Montage für System.dll - oder jedes andere Paket und dann mock erwarteten Renditen wie in:
InformationsquelleAutor Bahadır İsmail Aydın