Unit-Testing-Richtlinien

Question

Kennt jemand wo Unit-Tests Richtlinien und Empfehlungen zu finden? Ich möchte etwas haben, die die folgenden Arten von Themen (zum Beispiel) adressieren:

• Sollten Tests im selben Projekt als Anwendungslogik?
• Sollte ich Testklassen meine Logik Klassen zu spiegeln oder sollte ich nur so viele Testklassen, wie ich glaube, ich habe müssen?
• Wie soll ich meine Test Klassen, Methoden und Projekte nennen (wenn sie in verschiedenen Projekten gehen)
• Sollte privat, geschützt und interne Verfahren getestet werden, oder nur diejenigen, die öffentlich zugänglich sind?
• Sollte Modul- und Integrationstests getrennt werden?
• Sie haben einen gut Grund nicht zu 100% Testabdeckung zu haben?

Was soll ich nicht fragen nach, dass ich sein soll?

Eine Online-Ressource am besten wäre.

Answer 1

würde ich Kent Becks Buch über TDD empfehlen.

Auch müssen Sie gehen href="http://martinfowler.com/articles/mocksArentStubs.html" rel="noreferrer"> Martin Fowler Website

Wir sind ziemlich groß auf TDD, damit ich die Fragen in diesem Licht beantworten.

  

Sollten Tests werden im selben Projekt als Anwendungslogik?

Normalerweise halten wir unsere Tests in der gleichen Lösung, aber wir brechen Tests in separate DLL / Projekte, die die DLL / Projekte spiegeln sie testen, aber Namespaces mit den Tests in einem Sub-Namespace zu sein pflegen. Beispiel: Common / Common.Tests

  

Soll ich Testklassen meine Logik Klassen zu spiegeln oder soll ich nur so viele Testklassen, wie ich glaube, ich brauche zu haben?

Ja, sollten die Tests erstellt werden, bevor Klassen erstellt werden, und per Definition sollten Sie nur eine einzige Einheit in Isolation testen. Daher sollten Sie für jede Klasse in Ihrer Lösung eine Testklasse haben.

  

Wie soll ich meine Test Klassen, Methoden benennen und Projekte (wenn sie in verschiedenen Projekten gehen)

Ich mag das Verhalten betonen ist, was getestet wird, so, nachdem ich nenne typischerweise Testklassen SUT. Zum Beispiel, wenn ich eine User-Klasse hätte, würde ich die Testklasse nennt wie folgt:

public class UserBehavior

Methoden sollten benannt werden, um das Verhalten zu beschreiben, die Sie erwarten.

public void ShouldBeAbleToSetUserFirstName()

Die Projekte können jedoch genannt werden Sie wollen, aber in der Regel wollen, dass es ziemlich offensichtlich sein, welches Projekt es Testen ist. Siehe vorherige Antwort über Projektorganisation.

  

Sollte privat, geschützt und interne Verfahren getestet werden, oder nur diejenigen, die öffentlich zugänglich sind?

Auch hier mögen Sie Tests erwartetes Verhalten geltend zu machen, als ob Sie ein 3rd-Party-Verbraucher der Objekte erprobt wurden. Wenn Sie interne Implementierungsdetails prüfen dann Ihre Tests spröde sein. Sie möchten Ihr Test Ihnen die Freiheit zu refactor geben, ohne sich Gedanken über die vorhandene Funktionalität zu brechen. Wenn Ihr Test über Implementierungsdetails kennen, dann müssen Sie Ihre Tests ändern, wenn diese Details ändern.

  

Should Modul- und Integrationstests getrennt werden?

Ja, müssen Unit-Tests von Akzeptanz und Integrationstests isoliert werden. Trennung von Bedenken gilt für Tests als auch.

  

Sie haben einen guten Grund, nicht zu 100% Testabdeckung zu haben?

ich bekommen würde nicht auf der 100% Codeabdeckung Sache aufgehängt. 100% Codeabdeckung neigt ein gewisses Maß an Qualität in den Tests implizieren, aber das ist eine Legende. Sie können schreckliche Tests haben und immer noch 100% ige Abdeckung erhalten. Ich würde stattdessen verlassen sich auf einen guten Test Erste Mentalität. Wenn Sie immer einen Test schreiben, bevor Sie eine Zeile Code schreiben, dann werden Sie 100% Abdeckung gewährleisten, so dass es ein strittiger Punkt wird.

In der Regel, wenn Sie auf die Beschreibung der vollständigen Verhaltens Umfang der Klasse konzentrieren, dann haben Sie nichts zu befürchten. Wenn Sie Code Coverage eine Metrik dann faul Programmierer machen tun einfach nur genug, um diese Marke zu erfüllen, und Sie werden immer noch beschissen Tests. Stattdessen stark auf Peer-Reviews verlassen, wo die Tests als auch überprüft werden.

Answer 2

Es ist eine gute Frage. Wir wuchsen unsere eigenen organisch, und ich vermute, der beste Weg ist genau das. Es ist ein bisschen „Es kommt darauf an ...“ drin.

Wir löschten Tests im selben Projekt, in einem Sub-Namespace namens "UnitTes"

Unsere Testklassen spiegeln die Logik-Klasse, um die Verfolgung zu vereinfachen, wo die Tests in Bezug auf dem, was sie testen

Klassen wie die logische Klasse mit dem Namen werden sie testen, Methoden für das Szenario genannt werden, werden sie zu testen.

Wir haben leider nur schreiben Tests für die öffentlichen und internen Verfahren (Test im selben Projekt sind), und für 95% Abdeckung der Klasse wollen.

Ich möchte nicht zwischen „Einheit“ und „intergation“ unterscheiden. Um viel Zeit, um herauszufinden ausgegeben werden wird versucht, was was ist ... Tasche, die! Ein Test ist ein Test.

100% ist zu schwierig, die ganze Zeit zu erreichen. Wir streben 95%. Es gibt auch abnehmenden Ertrags, wie viel Zeit es dauert, dass die endgültige 5% bekommen und was sie tatsächlich fangen.

Das sind wir und was Umwelt und das Tempo geeignet heraus. Sie sind milage variieren. Denken Sie über Ihre envivonment nad die Persönlichkeiten, die beteiligt sind.

Ich freue mich zu sehen, was andere über dieses sagen!

Answer 3

Joshs Antwort richtig auf - nur einen Punkt der Klarstellung:

Der Grund, warum ich trenne Unit-Tests von Integrations- und Akzeptanztests ist die Geschwindigkeit. Ich benutze TDD. Ich muss nahe an ein sofortiges Feedback über die Codezeile ich gerade erstellt / geändert. Ich kann nicht, wenn ich bin mit voller Suiten der Integration und / oder Abnahmetests -. Tests, die realen Platten treffen, Real Networks und wirklich langsam und unberechenbar externe Systeme

Sie die Strahlen nicht überschreiten. Schlechte Dinge passieren wird, wenn Sie das tun.

Answer 4

Ich empfehle Sie inständig Test Driven Development zu lesen: Mit dem Beispiel und Testgetriebene Entwicklung: A Practical Guide Es ist zu viele Fragen für einzelnes Thema

Answer 5

Im Hinblick auf Ihre letzte Frage, nach meiner Erfahrung, der „gute“ Grund für die nicht darauf, auf 100% Testabdeckung ist, dass sie einen unverhältnismäßig hohen Aufwand nehmen die letzten paar Prozentpunkte, vor allem in größerer Codebasis zu erhalten. Als solches ist es eine Frage der Entscheidung, ob es sich lohnt, Ihre Zeit, wenn Sie diesen Punkt des abnehmenden Ertrags erreichen.

Answer 6

Um:

• Nein, es ist in der Regel am besten, sie in einem separaten Projekt einzubeziehen; es sei denn, Sie wollen in der Lage sein, Diagnose zur Laufzeit ausgeführt werden.
• Das Ideal ist 100% Codeabdeckung, die jede Zeile Code in jeder Routine in jeder Klasse bedeutet.
• Ich gehe mit ClassnameTest, ClassnameTest.MethodNameTestnumber
• Alles.
• Ich würde sagen, ja, wie Integrationstests müssen nicht ausgeführt werden, wenn die Einheit Tests fehlschlagen.
• Einfache Eigenschaften, die gerade eingestellt und ein Feld bekommen müssen nicht getestet werden.

Answer 7

Sollten Tests im selben Projekt wie Anwendungslogik?

Es hängt davon ab. Es gibt Kompromisse entweder Weg.

es in einem Projekt zu halten erfordert zusätzliche Bandbreite Ihr Projekt, zusätzliche Aufbauzeit zu verteilen und erhöht die Installation Stellfläche, und macht es leichter, die Fehler zu machen, Produktionslogik zu haben, die auf Testcode abhängig ist.

Auf der anderen Seite können separate Projekte halten machen es schwieriger, Tests zu schreiben Einbindung privater Methoden / Klassen (je nach Programmiersprache) und bewirkt, dass kleinere Verwaltung Ärger, wie machen eine neue Entwicklungsumgebung einrichten (zB wenn eine neue Entwickler schließen sich das Projekt) härter.

Wie viel diese unterschiedlichen Kosten variiert Materie durch Projekt, also gibt es keine allgemeingültige Antwort.

Soll ich Testklassen meine Logik Klassen zu spiegeln oder soll ich nur so viele Testklassen, wie ich glaube, ich brauche zu haben?

Nein.

Sie sollten Testklassen, die für gut einkalkuliert Testcode ermöglichen (das heißt minimal Vervielfältigung, klare Absicht, etc).

Der offensichtliche Vorteil der direkt die logischen Klassen in Ihrer Testklasse Spiegelung ist, dass sie es einfach machen, die Tests zu finden, um ein bestimmtes Stück Code entsprechen. Es gibt auch andere Möglichkeiten, um dieses Problem zu lösen, ohne die Flexibilität des Testcodes zu beschränken. Einfache Namenskonventionen für Testmodule und Klassen sind in der Regel genug.

Wie soll ich meine Test Klassen, Methoden und Projekte nennen (wenn sie in verschiedenen Projekten gehen)

Sie sollten sie so, dass Name:

• jede Testklasse und Prüfverfahren hat einen klaren Zweck und
• so, dass jemand für einen bestimmten Test (oder für Prüfungen über eine bestimmte Einheit) sucht sie leicht finden kann.

Sollten privat, geschützt und interne Verfahren getestet werden, oder nur diejenigen, die öffentlich zugänglich sind?

Oft nicht öffentliche Methoden sollten getestet werden. Es hängt davon ab, ob Sie genug Vertrauen von nur die Prüfung der öffentlichen Schnittstelle, oder wenn das Gerät Sie wirklich Tests sein wollen, ist nicht öffentlich zugänglich.

Sollten Modul- und Integrationstests getrennt werden?

Dies ist abhängig von der Wahl des Test-Framework (s). Habe je nachdem, was am besten mit Ihrem Test-Framework arbeitet (e) und macht es so, dass:

• sowohl die Modul- und Integrationstests, um ein Stück Kodexes sind leicht zu finden,
• es ist einfach nur die Unit-Tests laufen,
• es ist einfach nur die Integrationstests auszuführen,
• es ist einfach, alle Tests auszuführen.

Gibt es einen guten Grund, nicht zu 100% Testabdeckung zu haben?

Ja, es gibt einen guten Grund. Streng genommen „100% Testabdeckung“ bedeutet jede mögliche Situation in Ihrem Code ausüben und getestet. Das ist einfach nicht praktikabel für fast jedes Projekt zu erreichen.

Wenn Sie einfach nur „100% Testabdeckung“ so zu verstehen, dass jede Zeile des Quellcodes durch die Testsuite zu einem bestimmten Zeitpunkt ausgeübt wird, dann ist dies ein gutes Ziel, aber manchmal gibt es nur ein paar Zeilen an schwer zugänglichen Stellen die sind schwer mit automatisierten Tests zu erreichen. Wenn die Kosten für manuell diese Funktionalität in regelmäßigen Abständen zu überprüfen sind weniger als die Kosten für Verrenkungen durch die letzten fünf Zeilen zu erreichen, dann ist das ein guter Grund, nicht zu 100% -Linie Abdeckung zu haben.

Anstatt eine einfache Regel, die Sie 100% -Linie Abdeckung haben sollten, fördern Ihre Entwickler zu entdecken alle Lücken in Ihrem Test und Wege finden, um diese Lücken zu beheben, ob die Anzahl der Zeilen „ abgedeckt“verbessert. Mit anderen Worten, wenn Sie Linien bedeckt messen, dann werden Sie Ihre Linie coverge verbessern - aber was Sie wirklich wollen Qualität verbessert wird. Also vergessen Sie nicht, dass Zeilenabdeckung ist nur eine sehr grobe Annäherung an Qualität.