Wie wissen Sie, was zu testen, wenn Unit-Tests zu schreiben? [geschlossen]

https://stackoverflow.com/questions/62625

09-06-2019
|

Frage

C #, brauche ich eine Klasse namens User die einen Benutzernamen, ein Passwort Aktivflag hat, Vorname, Nachname, vollständiger Name, usw.

Es sollten Methoden authenticate und speichern ein Benutzer. Muss ich schreiben gerade einen Test für die Methoden? Und muss ich auch über die Prüfung der Eigenschaften sorgen, da sie .Net Getter und Setter sind?

Lösung

Viele große Antworten auf diese sind auch auf meine Frage: „ TDD Beginning - Herausforderungen Lösungen? Empfehlungen? "

Kann ich empfehlen auch einen Blick auf meine Blog-Post (was teilweise durch meine Frage inspiriert wurde), ich habe ein paar gutes Feedback auf das bekommt. Nämlich:

Ich weiß nicht, wo anfangen?


Starten Sie neu. Man denke nur über das Schreiben von Tests, wenn Sie neue schreiben   Code. Dies kann Nacharbeiten von alt   Code oder eine völlig neue Funktion.

Starten Sie einfach. Gehen Sie nicht wegzulaufen und versuchen, den Kopf Runde zu bekommen   ein Testrahmen sowie als   TDD-esque. Debug.Assert funktioniert gut.   Verwenden Sie es als Ausgangspunkt. Es ist nicht   Chaos mit Ihrem Projekt oder erstellen   Abhängigkeiten.

Starten Sie positiv. Sie versuchen, Ihr Handwerk zu verbessern, ein gutes Gefühl über   es. Ich habe viele Entwickler gesehen   gibt, die gerne stagnieren   und nicht versuchen, neue Dinge besser   sich. Sie tun das Recht   Sache, denken Sie daran, und es wird dazu beitragen,   stoppen Sie von Aufgeben.

Starten Sie bereit für eine Herausforderung. Es ist ziemlich schwer zu starten einlassen   testen. Erwarten Sie eine Herausforderung, aber   erinnern -. Herausforderungen überwunden werden können


Nur-Test für das, was Sie erwarten,

Ich hatte echte Probleme, wenn ich zum ersten Mal   begann, weil ich ständig saß   es versucht, alle, um herauszufinden,   mögliches Problem, das auftreten könnte, und   dann versuchen, es zu testen und zu beheben.   Dies ist ein schneller Weg, um Kopfschmerzen.   Die Prüfung sollte ein echter YAGNI sein   Prozess. Wenn Sie es wissen, ist ein   Problem, schreiben Sie dann einen Test für sie.   Ansonsten kümmern sich nicht darum.

Nur Test One Thing

Jeder Testfall sollte immer nur testen   eine Sache. Wenn Sie jemals selbst finden   setzen „und“ im Testfall Namen,   Sie tun etwas falsch gemacht.

Ich hoffe, das bedeutet, dass wir von „Getter und Setter“ weitergehen kann:)

Andere Tipps

Testen Sie Ihren Code, nicht die Sprache.

Ein Unit-Test wie:

Integer i = new Integer(7);
assert (i.instanceOf(integer));

ist nur dann sinnvoll, wenn Sie einen Compiler schreiben, und es gibt eine nicht-Null Chance, dass Ihre instanceof Methode funktioniert nicht.

Sie testen nicht Sachen, die Sie auf die Sprache verlassen können zu erzwingen. In Ihrem Fall, ich auf dem Authentifizieren konzentrieren würde und Methoden speichern -. Und ich würde Tests schreiben, die dafür gesorgt, sie anmutig NULL-Werte in einer oder allen dieser Felder umgehen konnte

Das hat mich in Unit-Tests und es machte mich sehr glücklich

Wir beginnen nur Unit-Tests zu tun. Für eine lange Zeit wusste ich, es wäre gut, es zu tun zu starten, aber ich hatte keine Ahnung, wie ich anfangen soll und was noch wichtiger ist, was zu testen.

Dann hatten wir ein wichtiges Stück Code in Accounting Programm neu zu schreiben. Dieser Teil war sehr komplex, da es viele verschiedene Szenarien beteiligt. Der Teil ich spreche ist eine Methode zu zahlen Umsatz und / oder Einkaufsrechnungen bereits in das Abrechnungssystem eingegeben.

Ich wusste nur nicht, wie es Codierung zu beginnen, da es so viele verschiedene Zahlungsmöglichkeiten waren. Eine Rechnung könnte 100 $ sein, aber der Kunde nur dann übertragen 99 $. Vielleicht haben Sie Verkaufsrechnungen an einem Kunden geschickt, aber Sie haben auch von diesen Kunden gekauft. So verkauft man ihn für $ 300, aber sie gekauft für 100 $. Sie können erwarten, dass Ihre Kunden Sie $ 200 zahlen den Restbetrag zu begleichen. Und was ist, wenn Sie verkauft für $ 500, aber der Kunde zahlt nur $ 250?

So hatte ich ein sehr komplexes Problem mit vielen Möglichkeiten zu lösen, dass ein Szenario perfekt funktionieren würde, aber würde auf einer anderen Art von invocie / Zahlungs Kombination falsch sein.

Dies ist, wo Unit-Tests kamen die Rettung.

Ich begann (im Testcode) zu schreiben, eine Methode, eine Liste von Rechnungen zu erstellen, sowohl für Verkäufe und Käufe. Dann schrieb ich eine zweite Methode, um die tatsächliche Zahlung zu erstellen. Normalerweise würde ein Benutzer diese Informationen über eine Benutzeroberfläche eingeben.

Dann habe ich das erste Testmethod, eine sehr einfache Zahlung einer einzigen Rechnung ohne Skonti zu testen. Die ganze Aktion im System passieren würde, wenn ein bankpayment in der Datenbank gespeichert werden würde. Wie man sehen kann ich eine Rechnung erstellt, erstellt eine Zahlung (eine Banktransaktion) und rettete die Transaktion auf der Festplatte. In meiner behauptet habe ich, was die enden richtige Zahlen in der Bank-Transaktion und in der verknüpften Rechnung sein sollte. Ich überprüfe die Anzahl der Zahlungen, die Zahlungsbeträge, der Rabattbetrag und den Rest der Rechnung nach der Transaktion.

Nachdem der Test lief ich in die Datenbank gehen und überprüfen ob das, was ich erwartet hatte da war.

Nach Ich schrieb den Test, begann ich die Zahlungsmethode Codierung (Teil der BankHeader Klasse). Bei der Codierung mit Code gestört ich nur den ersten Testdurchlauf zu machen. Ich glaube noch nicht über die anderen, komplexeren Szenarien.

lief ich den ersten Test, fixiert, um einen kleinen Fehler, bis mein Test würde passieren.

Dann begann ich mit einem Skonto den zweiten Test, diesmal zu schreiben arbeiten. Nachdem ich den Test schrieb modifizierte ich die Zahlungsmethode Rabatte zu unterstützen.

Während mit einem Zahlungsrabatt für Richtigkeit Prüfung, die ich getestet auch die einfache Zahlung. Beide Tests natürlich passieren sollte.

Dann habe ich mich auf dem Weg zu den komplexeren Szenarien.

1) Denken Sie an ein neues Szenario

2) Schreiben Sie einen Test für dieses Szenario

3) ausführen, den einzelnen Test, um zu sehen, ob es passieren würde

4) Falls es nicht klappt würde ich debug und den Code ändern, bis es passieren würde.

5) Während Code zu ändern Ich hielt alle Tests auf Lauf

Dies ist, wie ich es geschafft, meine sehr komplexe Zahlungsmethode zu erstellen. Ohne Unit-Tests habe ich nicht wissen, wie Codierung zu starten, schien das Problem überwältigend. Mit Tests konnte ich mit einer einfachen Methode beginnen und es Schritt für Schritt mit der Versicherung erweitern, dass die einfacheren Szenarien würden immer noch funktionieren.

Ich bin sicher, dass die Verwendung von Unit-Tests gespeichert mir ein paar Tage (oder Wochen) der Codierung und ist mehr oder weniger die Richtigkeit meiner Methode zu gewährleisten.

Wenn ich später von einem neuen Szenario denke, kann ich zu den Tests hinzufügen, es nur um zu sehen, ob es funktioniert oder nicht. Wenn nicht, kann ich den Code ändern, aber immer noch sicher sein, die anderen Szenarien noch richtig arbeiten. Dies wird Tage und Tage in der Wartung und Fehlerbehebung Phase speichern.

Ja, auch getestet Code kann noch Fehler habenWenn ein Benutzer Dinge tut man nicht denken oder verhindert ihn daran

Im Folgenden sind nur einige der Tests, die ich geschaffen, um meine Zahlungsmethode zu testen.

public class TestPayments
{
    InvoiceDiaryHeader invoiceHeader = null;
    InvoiceDiaryDetail invoiceDetail = null;
    BankCashDiaryHeader bankHeader = null;
    BankCashDiaryDetail bankDetail = null;



    public InvoiceDiaryHeader CreateSales(string amountIncVat, bool sales, int invoiceNumber, string date)
    {
        ......
        ......
    }

    public BankCashDiaryHeader CreateMultiplePayments(IList<InvoiceDiaryHeader> invoices, int headerNumber, decimal amount, decimal discount)
    {
       ......
       ......
       ......
    }


    [TestMethod]
    public void TestSingleSalesPaymentNoDiscount()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("119", true, 1, "01-09-2008"));
        bankHeader = CreateMultiplePayments(list, 1, 119.00M, 0);
        bankHeader.Save();

        Assert.AreEqual(1, bankHeader.BankCashDetails.Count);
        Assert.AreEqual(1, bankHeader.BankCashDetails[0].Payments.Count);
        Assert.AreEqual(119M, bankHeader.BankCashDetails[0].Payments[0].PaymentAmount);
        Assert.AreEqual(0M, bankHeader.BankCashDetails[0].Payments[0].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[0].InvoiceHeader.Balance);
    }

    [TestMethod]
    public void TestSingleSalesPaymentDiscount()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("119", true, 2, "01-09-2008"));
        bankHeader = CreateMultiplePayments(list, 2, 118.00M, 1M);
        bankHeader.Save();

        Assert.AreEqual(1, bankHeader.BankCashDetails.Count);
        Assert.AreEqual(1, bankHeader.BankCashDetails[0].Payments.Count);
        Assert.AreEqual(118M, bankHeader.BankCashDetails[0].Payments[0].PaymentAmount);
        Assert.AreEqual(1M, bankHeader.BankCashDetails[0].Payments[0].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[0].InvoiceHeader.Balance);
    }

    [TestMethod]
    [ExpectedException(typeof(ApplicationException))]
    public void TestDuplicateInvoiceNumber()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("100", true, 2, "01-09-2008"));
        list.Add(CreateSales("200", true, 2, "01-09-2008"));

        bankHeader = CreateMultiplePayments(list, 3, 300, 0);
        bankHeader.Save();
        Assert.Fail("expected an ApplicationException");
    }

    [TestMethod]
    public void TestMultipleSalesPaymentWithPaymentDiscount()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("119", true, 11, "01-09-2008"));
        list.Add(CreateSales("400", true, 12, "02-09-2008"));
        list.Add(CreateSales("600", true, 13, "03-09-2008"));
        list.Add(CreateSales("25,40", true, 14, "04-09-2008"));

        bankHeader = CreateMultiplePayments(list, 5, 1144.00M, 0.40M);
        bankHeader.Save();

        Assert.AreEqual(1, bankHeader.BankCashDetails.Count);
        Assert.AreEqual(4, bankHeader.BankCashDetails[0].Payments.Count);
        Assert.AreEqual(118.60M, bankHeader.BankCashDetails[0].Payments[0].PaymentAmount);
        Assert.AreEqual(400, bankHeader.BankCashDetails[0].Payments[1].PaymentAmount);
        Assert.AreEqual(600, bankHeader.BankCashDetails[0].Payments[2].PaymentAmount);
        Assert.AreEqual(25.40M, bankHeader.BankCashDetails[0].Payments[3].PaymentAmount);

        Assert.AreEqual(0.40M, bankHeader.BankCashDetails[0].Payments[0].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[1].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[2].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[3].PaymentDiscount);

        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[0].InvoiceHeader.Balance);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[1].InvoiceHeader.Balance);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[2].InvoiceHeader.Balance);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[3].InvoiceHeader.Balance);
    }

    [TestMethod]
    public void TestSettlement()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("300", true, 43, "01-09-2008")); //Sales
        list.Add(CreateSales("100", false, 6453, "02-09-2008")); //Purchase

        bankHeader = CreateMultiplePayments(list, 22, 200, 0);
        bankHeader.Save();

        Assert.AreEqual(1, bankHeader.BankCashDetails.Count);
        Assert.AreEqual(2, bankHeader.BankCashDetails[0].Payments.Count);
        Assert.AreEqual(300, bankHeader.BankCashDetails[0].Payments[0].PaymentAmount);
        Assert.AreEqual(-100, bankHeader.BankCashDetails[0].Payments[1].PaymentAmount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[0].InvoiceHeader.Balance);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[1].InvoiceHeader.Balance);
    }

Wenn sie wirklich trivial sind, dann nicht die Mühe Tests. Zum Beispiel, wenn sie wie diese umgesetzt werden;

public class User
{
    public string Username { get; set; }
    public string Password { get; set; }
}

Wenn auf der anderen Seite, Sie tun etwas Gescheites, (wie das Verschlüsseln und das Passwort in das Getter / Setter Entschlüsseln), dann geben Sie ihm einen Test.

Die Regel ist, dass Sie jedes Stück Logik zu testen, haben Sie schreiben. Wenn Sie einige spezifische Funktionen in den Getter und Setter umgesetzt ich glaube, sie wert Tests sind. Wenn sie nur Werte zu einigen privaten Felder zuweisen, nicht die Mühe.

Diese Frage scheint eine Frage der zu sein, wo soll man die Grenze ziehen auf welchen Methoden testen zu lassen und welche nicht.

Die Getter und Setter für Wertzuweisung wurden mit Konsistenz und künftiges Wachstum im Verstand, und voraussehend, dass einige Zeit auf der Straße die Setter / Getter in komplexere Operationen entwickeln kann. Es würde Sinn machen, Unit-Tests dieser Verfahren an Ort und Stelle zu setzen, auch aus Gründen der Konsistenz und künftigen Wachstums.

Code-Zuverlässigkeit, vor allem während der Änderung zusätzliche Funktionalität hinzufügen unterzieht, ist das primäre Ziel. Ich bin mir nicht bewusst, jemals jemand für einschließlich Setter / Getter in der Testmethodik gefeuert zu werden, aber ich bin sicher, dass es Menschen gibt, die wünschten, sie Methoden hatten getestet, die sie bewusst waren, dauern oder erinnern können einfache Set / Get-Wrapper waren, aber das war kein mehr der Fall.

Vielleicht erweitert ein weiteres Mitglied des Teams des Satzes / get-Methoden Logik enthalten, die jetzt getestet werden muss, aber nicht dann die Tests erstellen. Aber jetzt ist der Code diese Methoden aufrufen und Sie sind nicht bewusst, dass sie geändert und brauchen eine gründliche Prüfung und die Prüfung Sie in der Entwicklung tun und QA Sie den Mangel nicht auslösen, sondern echte Geschäftsdaten am ersten Tag der entbindet auslösen es.

Die beiden Mitspieler wird nun diskutiert, wer den Ball fallen gelassen und es versäumt, Unit-Tests setzen in, wenn die eingestellte / gemorpht wird Logik enthalten, die ausfallen können, aber nicht von einem Unit-Test abgedeckt. Der Mitspieler, der ursprünglich den Satz geschrieben / bekommt, wird es leichter hat aus diesem sauber kommen, wenn die Tests ab dem ersten Tag auf dem einfachen Satz umgesetzt wurden / wird.

Meine Meinung ist, dass ein paar Minuten von „verschwendet“ Zeit alle Methoden mit Unit-Tests abdeckt, auch trivialen, könnte Tage von Kopfschmerzen auf der Straße und den Verlust von Geld / Ruf des Unternehmens und der Verlust von jemandes Job speichern.

Und die Tatsache, dass Sie triviale Methoden haben wickeln mit Unit-Tests könnten von diesen Junior-Teamkollegen zu sehen, wenn sie die trivialen Methoden in nicht-triviale und sie veranlassen, um den Test zu aktualisieren, zu ändern, und jetzt niemand ist in Schwierigkeiten, weil die Defekt wurde erreicht Produktion enthalten sind.

Die Art, wie wir Code, und die Disziplin, die von unserem Code zu sehen ist, können andere helfen.

Eine weitere kanonische Antwort. Dies, glaube ich, von Ron Jeffries:

Test nur den Code, den Sie arbeiten möchten.

Test Standardcode ist eine Verschwendung von Zeit, aber wie Slavo sagt, wenn Sie eine Nebenwirkung auf Ihre Getter / Setter hinzufügen möchte, dann sollten Sie einen Test schreiben, um diese Funktionalität zu begleiten.

Wenn Sie testgetriebene Entwicklung zu tun, sollten Sie den Vertrag schreiben (zB Schnittstelle) zuerst, dann schreiben Sie den Test (s), die eine Schnittstelle zu trainieren, die die erwarteten Ergebnisse / Verhalten dokumentieren. Dann schreiben Sie Ihre Methoden selbst, ohne den Code in Ihre Unit-Tests zu berühren. Schließlich eine Code-Coverage-Tool greifen und stellen Sie sicher, dass Ihre Tests alle logischen Pfade in Ihrem Code ausüben.

Wirklich trivial Code wie Getter und Setter, die kein zusätzliches Verhalten haben als ein privates Feld Einstellung sind viel des Guten zu testen. In 3,0 C # hat sogar einige syntaktischen Zucker, wo der Compiler Pflege des privaten Bereich erfolgt, so dass Sie nicht, dass programmiert werden müssen.

ich in der Regel viele sehr einfacher Tests schreibt Überprüfung Verhalten, das ich von meinen Klassen erwarten. Auch wenn es ist einfach Sachen wie zwei Zahlen addieren. Ich schalte eine Menge zwischen einem einfachen Test zu schreiben und ein paar Zeilen Code zu schreiben. Der Grund dafür ist, dass ich dann um Code ändern kann, ohne Angst zu haben, ich brach Dinge, die ich nicht zustande denken.

Sie sollten alles testen. Gerade jetzt haben Sie Getter und Setter, aber eines Tages könnte sie etwas ändern, vielleicht Validierung oder etwas anderes zu tun. Die Tests, die Sie heute schreiben, wird morgen verwendet werden sicherzustellen, dass alles hält wie gewohnt auf die Arbeit zu machen. Wenn Sie Test schreiben, sollten Sie Überlegungen, wie vergessen „ist gerade trivial es ist“. In einem agilen oder Test-Driven Kontext sollten Sie künftig Refactoring testen nehmen. Auch haben sie versucht, in wirklich seltsam Werte wie extrem lange Strings oder andere „schlecht“ Inhalt setzen? Nun sollten Sie ... nie davon ausgehen, wie schlecht Ihr Code kann in Zukunft missbraucht werden.

Generell finde ich, dass umfangreiche Anwendertests schriftlich auf einer Seite ist, anstrengend. Auf der anderen Seite, wenn man davon immer gibt wertvolle Einblicke, wie Sie Ihre Anwendung funktionieren soll und hilft werfen Sie weg leicht (und falsche) Annahmen (wie: der Benutzername weniger als 1000 Zeichen immer lang sein wird)

Für einfache Module, die in einem Toolkit können am Ende oder in einem Open-Source-Projekttyp, sollten Sie so viel wie möglich mit den trivialen Getter und Setter testen. Das, was Sie im Auge behalten wollen, ist, dass ein Unit-Test zu erzeugen, wie Sie ein bestimmtes Modul schreiben ist ziemlich einfach und geradlinig. Hinzufügen von Getter und Setter ist minimal Code und kann ohne viel Gedanken behandelt werden. Sobald jedoch den Code in einem größeren System platziert wird, dieser zusätzliche Aufwand können Sie gegen Änderungen des zugrunde liegende System, wie Typ-Änderungen in einer Basisklasse schützen. Everthing Testen ist der beste Weg, um eine Regression zu haben, die abgeschlossen ist.

Es tut nicht weh, Unit-Tests für Ihre Getter und Setter zu schreiben. Gerade jetzt, können sie nur Feld get / Sets unter der Haube tun, aber in der Zukunft können Sie Validierungslogik haben oder inter Eigenschaft Abhängigkeiten, die getestet werden müssen. Es ist einfacher, es jetzt zu schreiben, während man darüber denken dann erinnern nachzurüsten, wenn diese Zeit jemals kommt.

in der Regel, wenn eine Methode nur für bestimmte Werte, Test für die Werte auf und über die Grenze definiert ist, was akzeptabel ist. Mit anderen Worten, stellen Sie sicher, dass Ihre Methode tut, was es tun soll ist, aber nichts mehr . Dies ist wichtig, denn wenn du gehst zum Scheitern verurteilt, Sie wollen früh zum Scheitern verurteilt.

In Vererbungshierarchien, stellen Sie sicher, für LSP Compliance zu testen.

Testing Standard-Getter und Setter scheinen nicht sehr nützlich für mich, wenn Sie später eine Validierung zu tun planen.

Als ich Unit-Tests im Rahmen der agilen Entwicklung verstehen, Mike, ja, müssen Sie die Getter und Setter testen (vorausgesetzt, sie öffentlich sichtbar sind). Das gesamte Konzept der Unit-Tests ist es, die Software-Einheit zu testen, die eine Klasse in diesem Fall ist, wie ein Box . Da die Getter und Setter von außen sichtbar sind, müssen Sie sie zusammen mit Authentifizieren und Speichern testen.

Wenn die Authentifizieren und speichern Methoden die Eigenschaften verwenden, dann werden Ihre Tests berühren indirekt die Eigenschaften. Solange die Eigenschaften nur Zugriff auf die Daten bereitstellt, so explizite Prüfung sollte nicht notwendig sein (es sei denn, Sie für 100% Deckung gehen).

Ich würde Ihre Getter und Setter testen. Je nachdem, wer den Code schreibt, ändern sich einige Menschen die Bedeutung der Getter / Setter-Methoden. Ich habe als Teil von Getter-Methoden Variableninitialisierung und andere Validierung gesehen. Um diese Art der Sache zu testen, werden Sie Unit-Tests wollen ausdrücklich, dass Code abdeckt.

Ich persönlich würde „alles testen, die brechen können“ und einfache Getter (oder noch besser Auto Eigenschaften) nicht brechen. Ich habe noch nie eine einfache return-Anweisung fehl, und dafür hat nie Test für sie. Wenn die Getter Berechnung in sich haben oder eine andere Form von Anweisungen, würde ich auf jeden Fall fügen Sie Tests für sie.

Ich persönlich verwenden Moq als Mock-Objekt-Framework und dann überprüfen, ob mein Objekt ruft die umgebende Objekte, wie es sein sollte.

Sie haben die Ausführung jeder Methode der Klasse mit UT und überprüfen Sie die Methode Rückgabewert zu decken. Dazu gehören Getter und Setter, insbesondere bei den Mitgliedern (Eigenschaften) sind komplexe Klassen, die während ihrer Initialisierung große Speicherzuweisung erfordert. Rufen Sie den Setter mit einigen sehr großen Zeichenfolge beispielsweise (oder etwas mit griechischen Symbolen) und prüfen Sie das Ergebnis korrekt ist (nicht abgeschnitten, Codierung ist gut e.t.c.)

Bei einfachen ganzen Zahlen, die auch gelten - was passiert, wenn man lange statt integer passieren? Das ist der Grund, warum Sie UT für schreiben:)

Ich würde nicht die aktuelle Einstellung von Eigenschaften testen. Ich wäre mehr besorgt darüber, wie diese Eigenschaften durch den Verbraucher bevölkert werden, und was sie bevölkern sie mit. Mit jedem Test haben Sie die Risiken, die mit der Zeit / Kosten für das Testen wiegen.

Sie sollten testen „jeden nicht-trivialen Codeblock“ Unit-Tests unter Verwendung von so weit wie möglich.

Wenn Sie Ihre Eigenschaften sind trivial und seine unwahrscheinlich, dass jemand einen Fehler in ihm einführen wird, dann sollte es sicher sein, um sie nicht Gerät zu testen.

Ihre Authentifizieren () und Save () Methoden aussehen gute Kandidaten für die Prüfung.

Im Idealfall würden Sie Ihre Unit-Tests durchgeführt, wie Sie die Klasse schreiben. Dies ist, wie Sie gemeint, es zu tun, wenn Test Driven Development mit. Sie fügen die Tests, wie Sie jede Funktion Punkt implementieren, um sicherzustellen, dass Sie die Randfälle mit Prüfhaube zu.

Das Schreiben der Tests danach ist viel schmerzhafter, aber machbar.

Hier ist, was ich in Ihrer Position tun würde:

eine Reihe von grundlegenden Tests schreiben, die die Kernfunktion testen.
Get NCover und es auf Ihre Tests laufen. Ihre Testabdeckung wird wahrscheinlich rund 50% an dieser Stelle.
Halten Tests hinzufügen, die Ihre Rand-Fälle abdecken, bis Sie Abdeckung von rund 80% -90%

Dies sollten Ihnen einen schönen Arbeitssatz von Unit-Tests geben, die als guten Puffer gegen Regressionen wirken.

Das einzige Problem bei diesem Ansatz ist, dass Code sein muss, entwickelt auf diese Weise überprüfbar zu sein. Wenn Sie irgendwelche Kupplungs Fehler gemacht früh, werden Sie nicht in der Lage sein, sehr leicht hohe Abdeckung zu erhalten.

Aus diesem Grunde ist es wirklich wichtig ist, die Tests zu schreiben, bevor Sie den Code schreiben. Es zwingt Sie, Code zu schreiben, die lose gekoppelt ist.

Sie nicht testen offensichtlich funktioniert (vorformulierten) Code. Also, wenn Ihre Getter und Setter sind nur „Property = Wert“ und „return Property“ es macht keinen Sinn, es zu testen.

Auch / set bekommt ungeradee Folgen haben, je nachdem, wie sie umgesetzt wurden, so sollten sie als Methoden behandelt werden.

Jeder Test von diesen müssen Parametersätze für die Eigenschaften angeben, die beide akzeptablen und nicht akzeptablen Eigenschaften zu definieren, die Anrufe zu gewährleisten Rückkehr / nicht bestanden in der erwarteten Weise.

Sie müssen auch bewusst Sicherheit gotchas sein, als ein Beispiel SQL-Injection und Test für diese.

Also ja, Sie müssen über die Prüfung der Eigenschaften sorgen.

Ich glaube, es zu testen Getter & Setter dumm ist, wenn sie nur eine einfache Bedienung machen. Persönlich schreibe ich keine komplexen Unit-Tests alle Nutzungsmuster zu decken. Ich versuche, genug Tests zu schreiben, um sicherzustellen, dass ich die normalen Ausführungsverhalten behandelt habe und wie viel Fehlerfall ich denken kann. Ich werde mehr Unit-Tests als Antwort auf die Fehlerberichte schreiben. Ich benutze Unit-Test, um sicherzustellen, der Code die Anforderungen erfüllt und zukünftige Änderung leichter zu machen. Ich fühle mich viel eher bereit, den Code zu ändern, wenn ich weiß, wenn ich etwas ein Test brechen wird scheitern.

Ich würde einen Test schreiben, für alles, was Sie das Schreiben von Code für das heißt testbar außerhalb der GUI-Schnittstelle.

Normalerweise jede Logik, die ich schreibe, dass jede Geschäftslogik hat ich in einer anderen Ebene oder Business-Logik-Schicht statt.

Dann Tests für etwas zu schreiben, die etwas tut, ist einfach zu tun.

Erster Durchgang, schreiben Sie einen Unit-Test für jede öffentliche Methode in Ihrem "Business Logic Layer".

Wenn ich eine Klasse wie folgt:

   public class AccountService
    {
        public void DebitAccount(int accountNumber, double amount)
        {

        }

        public void CreditAccount(int accountNumber, double amount)
        {

        }

        public void CloseAccount(int accountNumber)
        {

        }
    }

Das erste, was ich tun würde, bevor ich den Code geschrieben zu wissen, dass ich diese Aktionen hätte durchführen, um zu starten Unit-Tests zu schreiben.

   [TestFixture]
    public class AccountServiceTests
    {
        [Test]
        public void DebitAccountTest()
        {

        }

        [Test]
        public void CreditAccountTest()
        {

        }

        [Test]
        public void CloseAccountTest()
        {

        }
    }

Schreiben Sie Ihre Tests den Code zu validieren Sie geschrieben haben, etwas zu tun. Wenn Sie über eine Sammlung von Dingen laufen, und etwas über jeden von ihnen zu ändern, schreiben einen Test, die gleiche Sache und Assert tut, die tatsächlich passiert ist.

viele andere Ansätze gibt es dauern kann, nämlich behavoir Driven Development (BDD), das ist mehr beteiligt und nicht ein großer Platz mit Unit-Tests Fähigkeiten zu starten.

Die Moral der Geschichte also ist, alles testen, die alles tut Sie besorgt sein könnte, halten die Unit-Tests Tests bestimmte Dinge, die in der Größe klein sind, eine Menge Tests gut sind.

Halten Sie Ihre Geschäftslogik außerhalb der Schicht Benutzeroberfläche, so dass Sie leicht Tests für sie schreiben können, und Sie werden gut sein.

Ich empfehle TestDriven.Net oder ReSharper , da beide leicht in Visual Studio integrieren.

gut, wenn Sie denken, es kann brechen, einen Test für sie schreiben. Ich esse normalerweise nicht Setter / Getter testen, lässt aber sagt, dass Sie eine für User.Name machen, die Vor- und Nachnamen verketten, würde ich einen Test schreiben, so dass, wenn jemand den Auftrag für die Vor- und Nachnamen ändern, zumindest würde er wissen, änderte er etwas, das getestet wurde.

Die kanonische Antwort „Test alles, was möglicherweise brechen kann.“ Wenn Sie die Eigenschaften sind sicher nicht brechen, sie nicht testen.

Und wenn etwas gefunden wird, um gebrochen zu haben (Sie einen Fehler finden), natürlich bedeutet es Ihnen, es testen müssen. Schreiben Sie einen Test, den Fehler zu reproduzieren, beobachten Sie es nicht, dann beheben den Fehler, sehen Sie dann den Test zu bestehen.

Ich würde empfehlen, mehrere Tests für Ihre Authentifizieren und speichern Methoden zu schreiben. Neben den Erfolgsfall (in dem alle Parameter vorgesehen sind, ist alles richtig geschrieben, usw.), ist es gut Tests für verschiedene Fehlerfälle zu haben (falsche oder fehlende Parameter, nicht verfügbar Datenbankverbindungen ggf. usw.). Ich empfehle Pragmatische Unit Testing in C # mit NUnit als Referenz.

Wie schon andere gesagt haben, Unit-Tests für Getter und Setter sind übertrieben, es sei denn, es gibt bedingte Logik in Ihrer Getter und Setter.

Während es möglich ist, richtig erraten, wo Sie Ihren Code testen muss, ich glaube, im Allgemeinen Sie Metriken müssen diese Vermutung zu untermauern. Unit-Tests in meiner Sicht geht Hand in Hand mit Code-Coverage-Metriken.

Code mit vielen Tests, sondern eine kleine Abdeckung hat auch nicht getestet. Das heißt, Code mit 100% Deckung, aber nicht die boundry und Fehlerfall Prüfung ist auch nicht so toll.

Sie mögen eine Balance zwischen hohen Abdeckung (90% Minimum) und variablen Eingabedaten.

Denken Sie daran, für "Müll in" testen!

Auch ein Unit-Test ist kein Unit-Test, wenn es für einen Fehler überprüft. Einheit-Tests, die nicht über behauptet, oder mit bekannten Ausnahmen markiert wird einfach testen, dass der Code nicht stirbt, wenn run!

Sie müssen die Tests so gestalten, dass sie immer Ausfälle melden oder unerwartete / unerwünschte Daten!

Es macht unseren Code besser ... Zeitraum!

Eine Sache, uns Software-Entwickler vergessen, wenn Driven Development Test machen, ist das Ziel unseres Handelns. Wenn eine Einheit Test geschrieben wird, nachdem der Produktionscode bereits vorhanden ist, geht der Wert des Tests Weg nach unten (aber nicht vollständig verloren).

In dem wahren Geist für Unit-Tests, diese Tests sind nicht in erster Linie dort zu "Test" mehr unseren Code; oder 90% bis 100% besser Codeabdeckung zu erhalten. Diese sind alle Nebenleistungen der ersten, die Tests zu schreiben. Der große Gewinn ist, dass unser Produktionscode Ende viel besser durch den natürlichen Prozess des TDD geschrieben werden.

Um besser zu helfen, diese Idee in Verbindung stehen, kann folgende beim Lesen hilfreich sein:

Die Flawed Theory of Unit-Tests < br> Purposeful Software Development

Wenn wir das Gefühl, dass der Akt des Schreibens mehr Unit-Tests ist, was hilft uns, eine höhere Produktqualität zu gewinnen, dann können wir von einem Cargo Cult von Test Driven Development.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow