In der Computerprogrammierung ist Einheitsprüfung eine Methode, durch die individuelle Einheiten des Quellcodes, Sätze von einem oder mehr Computerprogramm-Modulen zusammen mit verbundenen Kontrolldaten, Gebrauch-Verfahren und Betriebsverfahren, geprüft werden, um zu bestimmen, ob sie für den Gebrauch passend sind. Intuitiv kann man eine Einheit als der kleinste prüfbare Teil einer Anwendung ansehen. In der Verfahrensprogrammierung einer Einheit konnte ein komplettes Modul sein, aber ist allgemeiner eine individuelle Funktion oder Verfahren. In der objektorientierten Programmierung einer Einheit ist häufig eine komplette Schnittstelle wie eine Klasse, aber konnte eine individuelle Methode sein. Einheitstests werden von Programmierern oder gelegentlich von weißen Kasten-Prüfern während des Entwicklungsprozesses geschaffen.

Ideal ist jeder Testfall von anderen unabhängig: Der Ersatz wie Methode-Stummel, nachgemachte Gegenstände, Fälschungen und Testgeschirre kann verwendet werden, um Prüfung eines Moduls bei der Isolierung zu helfen. Einheitstests werden normalerweise geschrieben und von Softwareentwicklern durchgeführt, um sicherzustellen, dass Code sein Design entspricht und sich wie beabsichtigt, benimmt. Seine Durchführung kann sich davon ändern (Bleistift und Papier) zum formalisieren sehr manuell zu sein, weil ein Teil dessen Automation baut.

Vorteile

Die Absicht der Einheitsprüfung ist, jeden Teil des Programms zu isolieren und zu zeigen, dass die individuellen Teile richtig sind. Ein Einheitstest stellt einen strengen, schriftlichen Vertrag zur Verfügung, den das Stück des Codes befriedigen muss. Infolgedessen gewährt es mehrere Vorteile.

Finden Sie Probleme früh

Einheitstests finden Probleme früh im Entwicklungszyklus.

In der Äußersten Programmierung und dem Gedränge, einem allgemeinen (und in einigen Interpretationen, erforderlich) soll Annäherung einen Einheitstest schaffen, bevor der Code selbst geschrieben wird, und setzen Sie fort, den Code in der Entwicklung durch den Test zu führen. Wenn es geht, wird dieser Code abgeschlossen betrachtet, und derselbe Einheitstest kann auf dieser Funktion oft durchgeführt werden, wie die größere Codebasis entwickelt wird. Da Probleme identifiziert werden, können sie leicht und so früh verfolgt werden.

Erleichtert Änderung

Einheitsprüfung erlaubt dem Programmierer dem Wiederfaktor-Code zu einem späteren Zeitpunkt, und stellen Sie sicher, dass das Modul noch richtig (z.B, in der Prüfung des rückwärts Gehens) arbeitet. Das Verfahren soll Testfälle für alle Funktionen und Methoden schreiben, so dass, wann auch immer eine Änderung eine Schuld verursacht, es schnell identifiziert und befestigt werden kann.

Sogleich verfügbare Einheitstests machen es leicht für den Programmierer zu überprüfen, ob ein Stück des Codes noch richtig arbeitet.

In dauernden Einheitsprobeumgebungen, durch die innewohnende Praxis der anhaltenden Wartung, werden Einheitstests fortsetzen, den beabsichtigten Gebrauch des rechtskräftigen und Codes angesichts jeder Änderung genau zu widerspiegeln. Abhängig von feststehenden Entwicklungsmethoden und Einheitstesteinschluss, zur Sekunde Genauigkeit kann aufrechterhalten werden.

Vereinfacht Integration

Einheitsprüfung kann Unklarheit in den Einheiten selbst reduzieren und kann in einer von unten nach oben prüfenden Stil-Annäherung verwendet werden. Durch die Prüfung der Teile eines Programms zuerst und dann die Prüfung der Summe seiner Teile wird Integrationsprüfung viel leichter.

Eine wohl durchdachte Hierarchie von Einheitstests kommt Integrationsprüfung nicht gleich. Die Integration mit peripherischen Einheiten sollte in Integrationstests, aber nicht in Einheitstests eingeschlossen werden. Integration, die normalerweise noch prüft, verlässt sich schwer auf Menschen, die manuell prüfen; auf höchster Ebene oder Prüfung des globalen Spielraums kann schwierig sein, solch zu automatisieren, dass manuelle Prüfung häufig schneller und preiswerter scheint.

Dokumentation

Einheitsprüfung stellt eine Art lebende Dokumentation des Systems zur Verfügung. Entwickler, die achten zu erfahren, was Funktionalität durch eine Einheit zur Verfügung gestellt wird, und wie man verwendet, kann es auf die Einheitstests schauen, um ein grundlegendes Verstehen der API der Einheit zu gewinnen.

Einheitstestfälle nehmen Eigenschaften auf, die zum Erfolg der Einheit kritisch sind. Diese Eigenschaften können passenden/unpassenden Gebrauch einer Einheit sowie negativer Handlungsweisen anzeigen, die durch die Einheit gefangen werden sollen. Ein Einheitstestfall, in und sich, dokumentiert diese kritischen Eigenschaften, obwohl sich viele Softwareentwicklungsumgebungen allein laut des Codes nicht verlassen, um das Produkt in der Entwicklung zu dokumentieren.

Im Vergleich ist gewöhnliche Bericht-Dokumentation gegen das Treiben von der Durchführung des Programms empfindlicher und wird so überholt werden (z.B, Designänderungen, Eigenschaft, kriecht entspannte Methoden im Halten von Dokumenten aktuell).

Design

Wenn Software mit einer probegefahrenen Annäherung entwickelt wird, kann der Einheitstest den Platz des formellen Designs nehmen. Jeder Einheitstest kann als ein Designelement-Spezifizieren Klassen, Methoden und erkennbares Verhalten gesehen werden. Das folgende javanische Beispiel wird helfen, diesen Punkt zu illustrieren.

Hier ist eine Testklasse, die mehrere Elemente der Durchführung angibt. Erstens, dass es eine Schnittstelle genannt die Viper und eine Einführen-Klasse mit einem Nullargument-Konstrukteur genannt AdderImpl geben muss. Es setzt fort zu behaupten, dass die Viper-Schnittstelle eine Methode nennen lassen sollte, tragen mit zwei Rahmen der ganzen Zahl bei, der eine andere ganze Zahl zurückgibt. Es gibt auch das Verhalten dieser Methode für einen kleinen Wertbereich an.

öffentliche Klasse TestAdder {\

öffentliche Leere testSum {\

Viper-Viper = neuer AdderImpl ;

//kann es positive Zahlen hinzufügen?

behaupten Sie (adder.add (1, 1) == 2);

behaupten Sie (adder.add (1, 2) == 3);

behaupten Sie (adder.add (2, 2) == 4);

//ist Null neutral?

behaupten Sie (adder.add (0, 0) == 0);

//kann es negative Zahlen hinzufügen?

behaupten Sie (adder.add (-1,-2) ==-3);

//kann es einen positiven und eine Verneinung hinzufügen?

behaupten Sie (adder.add (-1, 1) == 0);

//wie steht's mit größeren Zahlen?

behaupten Sie (adder.add (1234, 988) == 2222);

}\

}\

</Quelle>

In diesem Fall handelt der Einheitstest, zuerst geschrieben, als ein Designdokument, das die Form und das Verhalten einer gewünschten Lösung, aber nicht die Durchführungsdetails angibt, die für den Programmierer verlassen werden. Im Anschluss an "machen die einfachste Sache, die vielleicht" Praxis arbeiten konnte, wird die leichteste Lösung, die den Test wird gehen lassen, unten gezeigt.

verbinden Sie Viper {\

interne Nummer trägt (interne Nummer a, interne Nummer b) bei;

}\

Klasse AdderImpl führt Viper {\durch

interne Nummer fügt (interne Nummer a, interne Nummer b) {\hinzu

kehren Sie + b zurück;

}\}\</Quelle>

Verschieden von anderen Diagramm-basierten Designmethoden mit einem Einheitstest weil hat ein Design einen bedeutenden Vorteil. Das Designdokument (der Einheitstest selbst) kann verwendet werden, um nachzuprüfen, dass die Durchführung am Design klebt. Mit der Einheitstest-Designmethode werden die Tests nie gehen, wenn der Entwickler die Lösung gemäß dem Design nicht durchführt.

Es ist wahr, dass Einheitsprüfung an etwas von der Zugänglichkeit eines Diagramms Mangel hat, aber UML Diagramme werden jetzt für am meisten neuere Sprachen durch freie Werkzeuge (gewöhnlich verfügbar als Erweiterungen auf IDEN) leicht erzeugt. Freie Werkzeuge, wie diejenigen, die auf dem xUnit Fachwerk gestützt sind, gliedern zu einem anderen System die grafische Übergabe einer Ansicht für den menschlichen Verbrauch aus.

Trennung der Schnittstelle von der Durchführung

Weil einige Klassen Verweisungen auf andere Klassen haben können, kann sich das Prüfen einer Klasse oft in die Prüfung einer anderen Klasse ergießen. Ein allgemeines Beispiel davon ist Klassen, die von einer Datenbank abhängen: Um die Klasse zu prüfen, schreibt der Prüfer häufig Code, der mit der Datenbank aufeinander wirkt. Das ist ein Fehler, weil ein Einheitstest gewöhnlich seiner eigenen Klassengrenze nicht nach draußen gehen sollte, und besonders solche Grenzen des Prozesses/Netzes nicht durchqueren sollte, weil das unannehmbare Leistungsprobleme ins Einheitstestgefolge einführen kann. Überfahrt solcher Einheitsgrenzen verwandelt Einheitstests in Integrationstests, und wenn Testfälle scheitern, macht weniger verständlich, welcher Bestandteil den Misserfolg verursacht. Siehe auch Fälschungen, Spott und Integration prüft

Statt dessen sollte der Softwareentwickler eine abstrakte Schnittstelle um die Datenbankabfragen schaffen, und dann diese Schnittstelle mit ihrem eigenen nachgemachten Gegenstand durchführen. Durch das Entziehen dieser notwendigen Verhaftung aus dem Code (provisorisch die wirksame Nettokopplung reduzierend), kann die unabhängige Einheit mehr gründlich geprüft werden, als es vorher erreicht worden sein kann. Das läuft auf eine höhere Qualitätseinheit hinaus, die auch haltbarer ist.

Parameterized Unit Testing (PUT)

Parametrisierte Einheitstests (STELLEN) sind Tests, die Rahmen nehmen. Verschieden von traditionellen Einheitstests, die gewöhnlich geschlossene Methoden sind, STELLT nehmen jeden Satz von Rahmen. STELLT sind durch JUnit 4 und verschiedenes.NET-Testfachwerk unterstützt worden. Passende Rahmen für die Einheitstests können manuell geliefert werden oder werden in einigen Fällen durch das Testfachwerk automatisch erzeugt. Verschiedene Industrieprobewerkzeuge bestehen auch, um Testeingänge dafür zu erzeugen, STELLT.

Einheitsprobebeschränkungen

Wie man

erwarten kann, fängt Prüfung jeden Fehler im Programm nicht: Es ist unmöglich, jeden Ausführungspfad in allen außer den meisten trivialen Programmen zu bewerten. Dasselbe ist für die Einheitsprüfung wahr. Zusätzlich prüft Einheit, die definitionsgemäß nur prüft, die Funktionalität der Einheiten selbst. Deshalb wird es Integrationsfehler oder breitere Systemebene-Fehler (wie Funktionen nicht fangen, die über vielfache Einheiten oder Nichtfunktionsprüfungsgebiete wie Leistung durchgeführt sind). Einheitsprüfung sollte in Verbindung mit anderen Softwareprobetätigkeiten getan werden. Wie alle Formen der Softwareprüfung können Einheitstests nur die Anwesenheit von Fehlern zeigen; sie können die Abwesenheit von Fehlern nicht zeigen.

Softwareprüfung ist ein kombinatorisches Problem. Zum Beispiel verlangt jede boolean Entscheidungsbehauptung mindestens zwei Tests: ein mit einem Ergebnis von "wahren" und ein mit einem Ergebnis von "falschen". Infolgedessen, für jede Linie des schriftlichen Codes, brauchen Programmierer häufig 3 bis 5 Linien des Testcodes. Das nimmt offensichtlich Zeit in Anspruch, und seine Investition kann der Anstrengung nicht wert sein. Es gibt auch viele Probleme, die überhaupt - zum Beispiel diejenigen nicht leicht geprüft werden können, die nichtdeterministisch sind oder vielfache Fäden einschließen. Außerdem ist das Schreiben des Codes für einen Einheitstest so wahrscheinlich, mindestens so verwanzt zu sein, wie der Code, den es prüft. Fred Brooks in Den Mythischen Arbeitsmonat-Notierungen: Bringen Sie nie zwei Chronometer ins Meer. Nehmen Sie immer ein oder drei. Die Bedeutung, wenn zwei Chronometer widersprechen, wie wissen Sie, welcher ist richtig?

Um die beabsichtigten Vorteile der Einheitsprüfung zu erhalten, ist strenge Disziplin während des Softwareentwicklungsprozesses erforderlich. Es ist notwendig, sorgfältige Aufzeichnungen nicht nur der Tests zu behalten, die durchgeführt worden sind, sondern auch aller Änderungen, die zum Quellcode davon oder jeder anderen Einheit in der Software gemacht worden sind. Der Gebrauch eines Versionsregelsystems ist notwendig. Wenn eine spätere Version der Einheit einem besonderen Test fehlt, den es vorher bestanden hatte, kann die Versionskontrolle-Software eine Liste der Quellcodeänderungen zur Verfügung stellen (wenn irgendwelcher), die auf die Einheit seit dieser Zeit angewandt worden sind.

Es ist auch notwendig, einen nachhaltigen Prozess durchzuführen, um sicherzustellen, dass Testfall-Misserfolge täglich nachgeprüft und sofort gerichtet werden. Wenn solch ein Prozess nicht durchgeführt und in den Arbeitsablauf der Mannschaft tief verwurzelt wird, wird sich die Anwendung asynchron mit dem Einheitstestgefolge entwickeln, falschen positives vergrößernd und die Wirksamkeit des Testgefolges reduzierend.

Anwendungen

Äußerste Programmierung

Einheitsprüfung ist der Eckstein der äußersten Programmierung, die sich auf ein automatisiertes Einheitsprobefachwerk verlässt. Dieses automatisierte Einheitsprobefachwerk kann entweder Dritter, z.B, xUnit, oder geschaffen innerhalb der Entwicklungsgruppe sein.

Äußerste Programmierung verwendet die Entwicklung von Einheitstests auf die probegefahrene Entwicklung. Der Entwickler schreibt einen Einheitstest, der entweder eine Softwarevoraussetzung oder einen Defekt ausstellt. Dieser Test wird scheitern, weil entweder die Voraussetzung noch nicht durchgeführt wird, oder weil es absichtlich einen Defekt im vorhandenen Code ausstellt. Dann schreibt der Entwickler den einfachsten Code, um den Test, zusammen mit anderen Tests, Pass zu machen.

Der grösste Teil des Codes in einem System ist Einheit geprüft, aber nicht notwendigerweise alle Pfade durch den Code. Äußerste Programmierung beauftragt einen "Test alles, was vielleicht" Strategie, über den traditionellen "Test jede Ausführung Pfad" Methode brechen kann. Das bringt Entwickler dazu, weniger Tests zu entwickeln, als klassische Methoden, aber das ist nicht wirklich ein Problem, mehr eine Neuformulierung der Tatsache, weil klassischen Methoden selten jemals methodisch genug für alle gründlich zu prüfenden Ausführungspfade gefolgt worden ist. Äußerste Programmierung erkennt einfach an, dass Prüfung selten erschöpfend ist (weil es häufig zu teuer und zeitraubend ist, um wirtschaftlich lebensfähig zu sein), und Leitung darauf zur Verfügung stellt, wie man beschränkte Mittel effektiv einstellt.

Entscheidend wird der Testcode als ein Projektkunsterzeugnis der ersten Klasse betrachtet, in dem er an derselben Qualität wie der Durchführungscode mit der ganzen entfernten Verdoppelung aufrechterhalten wird. Entwickler veröffentlichen Einheitsprobecode zum Codebehältnis in Verbindung mit dem Code, den es prüft. Die gründliche Einheitsprüfung der äußersten Programmierung erlaubt die Vorteile, die oben, wie einfachere und überzeugtere Codeentwicklung und Wiederfactoring, vereinfachte Codeintegration, genaue Dokumentation und mehr Moduldesigns erwähnt sind. Diese Einheitstests werden auch ständig als eine Form des Tests des rückwärts Gehens durchgeführt.

Einheitsprüfung ist auch zum Konzept des Auftauchenden Designs kritisch. Da Auftauchendes Design auf das Wiederfactoring schwer abhängig ist, sind Einheitstests integrierter Bestandteil.

Techniken

Einheitsprüfung wird allgemein automatisiert, aber kann noch manuell durchgeführt werden. Der IEEE bevorzugt ein über den anderen nicht. Eine manuelle Annäherung an die Einheitsprüfung kann ein schrittweises Unterrichtsdokument verwenden. Dennoch ist das Ziel in der Einheitsprüfung, eine Einheit zu isolieren und seine Genauigkeit gültig zu machen. Automation ist effizient, um das zu erreichen, und ermöglicht die vielen in diesem Artikel verzeichneten Vorteile. Umgekehrt, wenn nicht geplant sorgfältig kann ein unbesonnener manueller Einheitstestfall als ein Integrationstestfall durchführen, der viele Softwarebestandteile einschließt, und schließen Sie so das Zu-Stande-Bringen von die meisten wenn nicht alle für die Einheitsprüfung gegründeten Absichten aus.

Die Wirkung der Isolierung völlig zu begreifen, während er eine automatisierte Annäherung, die Einheit oder den Codekörper unter dem Test verwendet, wird innerhalb eines Fachwerks außerhalb seiner natürlichen Umgebung durchgeführt. Mit anderen Worten wird es außerhalb des Produktes oder Benennens des Zusammenhangs durchgeführt, für den es ursprünglich geschaffen wurde. Die Prüfung auf solch eine isolierte Weise offenbart unnötige Abhängigkeiten zwischen dem Code, der wird prüft und anderen Einheiten oder Datenräumen im Produkt. Diese Abhängigkeiten können dann beseitigt werden.

Mit einem Automationsfachwerk codiert der Entwickler Kriterien in den Test, um die Genauigkeit der Einheit nachzuprüfen. Während der Testfall-Ausführung loggt das Fachwerk Tests, die jedem Kriterium fehlen. Vieles Fachwerk wird auch diese erfolglosen Testfälle automatisch beflaggen und sie in einer Zusammenfassung melden. Abhängig von Strenge eines Misserfolgs kann das Fachwerk nachfolgende Prüfung halten.

Demzufolge ist Einheitsprüfung traditionell ein motivator für Programmierer, um decoupled und zusammenhaltende Codekörper zu schaffen. Diese Praxis fördert gesunde Gewohnheiten in der Softwareentwicklung. Designmuster, Einheitsprüfung und Wiederfactoring arbeiten häufig zusammen, so dass die beste Lösung erscheinen kann.

Einheitsprobefachwerk

Einheitsprobefachwerk ist meistenteils Drittprodukte, die als ein Teil des Bearbeiter-Gefolges nicht verteilt werden. Sie helfen, den Prozess der Einheitsprüfung zu vereinfachen, für ein großes Angebot an Sprachen entwickelt worden sein. Beispiele, Fachwerk zu prüfen, schließen offene Quelllösungen wie das verschiedene codegesteuerte Probefachwerk bekannt insgesamt als xUnit und Eigentums/kommerzielllösungen wie TBrun, Isolator.NET, Isolator ++, Testwell CTA ++ und VectorCAST/C ++ ein.

Es ist allgemein möglich, Einheitsprüfung ohne die Unterstützung eines spezifischen Fachwerks durch das Schreiben des Kundencodes durchzuführen, der die Einheiten unter dem Test ausübt und Behauptungen, das Ausnahme-Berühren oder die anderen Kontrollfluss-Mechanismen verwendet, Misserfolg Zeichen zu geben. Die Einheitsprüfung ohne ein Fachwerk ist darin wertvoll es gibt eine Barriere für den Zugang für die Adoption der Einheitsprüfung; spärliche Einheitstests zu haben, ist kaum besser als, niemanden überhaupt zu haben, wohingegen sobald ein Fachwerk im Platz, das Hinzufügen ist, dass Einheitstests relativ leicht werden. In einem Fachwerk werden viele fortgeschrittene Einheitstesteigenschaften vermisst oder müssen handcodiert werden.

Sprachebene-Einheitsprobeunterstützung

Einige Programmiersprachen unterstützen direkt Einheitsprüfung. Ihre Grammatik erlaubt die direkte Behauptung von Einheitstests, ohne eine Bibliothek (entweder Dritter oder Standard) zu importieren. Zusätzlich können die boolean Bedingungen der Einheitstests in derselben Syntax wie boolean Ausdrücke ausgedrückt werden, die im Nichteinheitstestcode, solcher als verwendet sind, was für und Behauptungen verwendet wird.

Sprachen, die direkt Einheitsprüfung unterstützen, schließen ein:

C#

• Corba
• D
• Java

Siehe auch

• Charakterisierungstest
• Teilbasierte Brauchbarkeit, die prüft
• Designprädikate
• Design durch den Vertrag
• Äußerste Programmierung
• Integration, die prüft
• Liste des Einheitsprobefachwerks
• Rückwärts Gehen, das prüft
• Softwarearchäologie
• Software, die prüft
• Testfall
• Probegefahrene Entwicklung
• xUnit - eine Familie des Einheitsprobefachwerks.

Zeichen

Außenverbindungen

• Einheitsproberichtlinien von GeoSoft
• Prüfen Sie gesteuerte Entwicklung (der Wiki von Ward Cunningham)
• Einheit, die 101 für den Nichtprogrammierer Prüft
• Schrittweises Handbuch zur JPA-ermöglichten Einheitsprüfung (Java EE)