Unit-Tests , auch Komponententests oder Modultests genannt, sind eine Form des Softwaretests , bei der isolierter Quellcode getestet wird, um das erwartete Verhalten zu überprüfen. [ 1 ]

Unit-Tests beschreiben Tests, die auf Komponentenebene ausgeführt werden, im Gegensatz zu Tests auf Integrations- oder Systemebene . [ 2 ]

Geschichte

Unit-Tests, als Prinzip zum separaten Testen kleinerer Teile großer Softwaresysteme, reichen bis in die Anfänge der Softwareentwicklung zurück. Im Juni 1956 stellte H. D. Benington auf dem Symposium der US Navy über fortgeschrittene Programmiermethoden für Digitalrechner das SAGE- Projekt vor. Dieses verfolgte einen spezifikationsbasierten Ansatz, bei dem auf die Codierungsphase ein Parametertest zur Validierung der Komponenten-Subprogramme anhand ihrer Spezifikation und anschließend ein Assemblierungstest der zusammengefügten Teile folgte. [ 3 ] [ 4 ]

1964 wurde ein ähnlicher Ansatz für die Software des Mercury-Projekts beschrieben , bei dem einzelne, von verschiedenen Programmierern entwickelte Einheiten vor ihrer Integration „Unit-Tests“ unterzogen wurden. [ 5 ] 1969 erschienen die Testmethoden strukturierter: Unit-Tests, Komponententests und Integrationstests validierten gemeinsam die separat geschriebenen Einzelteile und deren schrittweise Zusammenführung zu größeren Blöcken. [ 6 ] Einige Ende der 1960er-Jahre verabschiedete öffentliche Standards, wie MIL-STD-483 [ 7 ] und MIL-STD-490, trugen weiter zur breiten Akzeptanz von Unit-Tests in großen Projekten bei.

Unit-Tests waren damals interaktiv [ 4 ] oder automatisiert [ 8 ] und verwendeten entweder codierte Tests oder Tools zur Aufzeichnung und Wiedergabe von Tests. 1989 beschrieb Kent Beck in „ Simple Smalltalk Testing: With Patterns “ ein Testframework für Smalltalk (später SUnit genannt ) . 1997 entwickelten und veröffentlichten Kent Beck und Erich Gamma JUnit , ein Unit-Test-Framework, das sich bei Java- Entwicklern großer Beliebtheit erfreute . [ 9 ] Google setzte ab etwa 2005/2006 auf automatisierte Tests. [ 10 ]

Einheit

Eine Einheit ist definiert als ein einzelnes Verhalten des zu testenden Systems (SUT), das üblicherweise einer Anforderung entspricht. Während eine Einheit einer einzelnen Funktion oder einem Modul (in der prozeduralen Programmierung ) oder einer einzelnen Methode oder Klasse (in der objektorientierten Programmierung ) entsprechen kann, entsprechen Funktionen/Methoden und Module/Klassen nicht notwendigerweise Einheiten. Aus Sicht der Systemanforderungen ist nur der Systemumfang relevant; daher definieren nur Einstiegspunkte in extern sichtbare Systemverhaltensweisen Einheiten. [ 11 ]

Ausführung

Unit-Tests können manuell oder automatisiert durchgeführt werden . Zu den Vorteilen automatisierter Tests gehören: häufige Testdurchführung, keine zusätzlichen Personalkosten und konsistente sowie reproduzierbare Testergebnisse.

Das Testen wird häufig von dem Programmierer durchgeführt, der den zu testenden Code schreibt und modifiziert. Unit-Tests können als Teil des Programmierprozesses betrachtet werden.

Prüfkriterien

Während der Entwicklung kann ein Programmierer Kriterien oder Ergebnisse, von denen bekannt ist, dass sie gut sind, in den Test einprogrammieren, um die Korrektheit der Einheit zu überprüfen.

Während der Testausführung protokollieren die Frameworks Tests, die ein Kriterium nicht erfüllen, und fassen diese in einer Zusammenfassung zusammen.

Hierfür wird am häufigsten der Ansatz Test - Funktion - Erwartungswert verwendet.

Testfall

In der Softwareentwicklung ist ein Testfall die Spezifikation der Eingaben, Ausführungsbedingungen, des Testablaufs und der erwarteten Ergebnisse eines einzelnen Tests, der ausgeführt wird, um ein bestimmtes Testziel zu erreichen , beispielsweise einen bestimmten Programmablauf zu testen oder die Einhaltung einer spezifischen Anforderung zu überprüfen. [ 12 ] Testfälle bilden die Grundlage für methodisches, nicht willkürliches Testen. Durch die Erstellung einer Testfallsammlung lässt sich die gewünschte Testabdeckung der zu testenden Software erzielen. Formal definierte Testfälle ermöglichen es, dieselben Tests wiederholt gegen verschiedene Softwareversionen auszuführen und so effektive und konsistente Regressionstests durchzuführen . [ 13 ]

Test-Doppel

Ein Test-Double ist eine Softwarekomponente, die in der Softwaretestautomatisierung eingesetzt wird und eine Abhängigkeit erfüllt , sodass der Test nicht vom Produktionscode abhängen muss. Ein Test-Double stellt Funktionalität über eine Schnittstelle bereit , die die zu testende Software nicht vom Produktionscode unterscheiden kann.

Parametrisierter Test

Ein parametrisierter Test ist ein Test, der eine Reihe von Werten akzeptiert, um mit verschiedenen Eingabewerten ausgeführt werden zu können. Ein Testframework, das parametrisierte Tests unterstützt, ermöglicht das Kodieren von Parametersätzen und das Ausführen des Tests mit jedem Satz.

Durch den Einsatz parametrisierter Tests lässt sich die Duplikation von Testcode reduzieren.

Parametrisierte Tests werden von TestNG , JUnit , [ 14 ] XUnit und NUnit sowie von verschiedenen JavaScript-Testframeworks unterstützt.

Die Parameter für die Unit-Tests können manuell codiert oder in manchen Fällen automatisch vom Testframework generiert werden. In den letzten Jahren wurde die Unterstützung für das Schreiben leistungsfähigerer (Unit-)Tests erweitert, indem das Konzept von Theorien genutzt wird. Dabei handelt es sich um Testfälle, die dieselben Schritte ausführen, jedoch mit zur Laufzeit generierten Testdaten, im Gegensatz zu regulären parametrisierten Tests, die dieselben Ausführungsschritte mit vordefinierten Eingabesätzen verwenden. [ 15 ]

Code-Sichtbarkeit

Testcode benötigt Zugriff auf den zu testenden Code. Tests sollten jedoch die üblichen Designziele wie Informationskapselung , Datenkapselung und die Trennung von Belangen nicht beeinträchtigen . Um Zugriff auf Code zu ermöglichen, der nicht über die externe API zugänglich ist, können Unit-Tests im selben Projekt oder Modul wie der zu testende Code platziert werden.

Auch in der objektorientierten Programmierung bietet dies möglicherweise keinen Zugriff auf private Daten und Methoden. Daher kann zusätzlicher Aufwand für Unit-Tests erforderlich sein. In Java und anderen Sprachen kann ein Entwickler mithilfe von Reflection auf private Felder und Methoden zugreifen. [ 16 ] Alternativ kann eine innere Klasse verwendet werden, die die Unit-Tests enthält, sodass diese Zugriff auf die Member und Attribute der umschließenden Klasse haben. Im .NET Framework und einigen anderen Programmiersprachen können partielle Klassen verwendet werden, um private Methoden und Daten für die Tests zugänglich zu machen.

Es ist wichtig, dass Code, der ausschließlich für Tests dient, nicht im Produktionscode verbleibt. In C und anderen Sprachen können Compilerdirektiven wie `@Test` #if DEBUG ... #endifum solche zusätzlichen Klassen und den gesamten testbezogenen Code gesetzt werden, um zu verhindern, dass diese in den veröffentlichten Code kompiliert werden. Das bedeutet, dass der veröffentlichte Code nicht exakt dem entspricht, was im Unit-Test geprüft wurde. Die regelmäßige Ausführung weniger, aber umfassenderer End-to-End-Integrationstests im finalen Release-Build kann (unter anderem) sicherstellen, dass kein Produktionscode existiert, der subtil auf Aspekte der Testumgebung angewiesen ist .

Unter Entwicklern gibt es Diskussionen darüber, ob es überhaupt sinnvoll ist, private Methoden und Daten zu testen. Einige argumentieren, dass private Elemente lediglich Implementierungsdetails darstellen, die sich ändern können und dies auch dürfen sollten, ohne dass dadurch zahlreiche Tests beeinträchtigt werden. Daher sollte es genügen, jede Klasse über ihre öffentliche Schnittstelle oder die Schnittstelle ihrer Unterklasse zu testen, die in manchen Sprachen als „geschützte“ Schnittstelle bezeichnet wird. [ 17 ] Andere wiederum meinen, dass wichtige Aspekte der Funktionalität in privaten Methoden implementiert sein können und deren direktes Testen den Vorteil kleinerer und direkterer Unit-Tests bietet. [ 18 ] [ 19 ]

Testgetriebene Entwicklung

Bei der testgetriebenen Entwicklung (TDD) werden Unit-Tests geschrieben, bevor der zugehörige Produktionscode erstellt wird. Man beginnt mit einem fehlgeschlagenen Test, fügt dann gerade so viel Produktionscode hinzu, dass der Test erfolgreich ist, refaktoriert den Code anschließend sinnvoll und wiederholt den Vorgang, indem man einen weiteren fehlgeschlagenen Test hinzufügt.

Wert

Unit-Tests sollen sicherstellen, dass die Einheiten ihren Spezifikationen entsprechen und sich wie vorgesehen verhalten. [ 20 ]

Indem man zunächst Tests für die kleinsten testbaren Einheiten und anschließend für die zusammengesetzten Verhaltensweisen zwischen diesen Einheiten schreibt, lassen sich umfassende Tests für komplexe Anwendungen erstellen. [ 20 ]

Ein Ziel von Unit-Tests ist es, jeden Teil des Programms zu isolieren und dessen Korrektheit nachzuweisen. [ 1 ] Ein Unit-Test stellt einen strengen, schriftlichen Vertrag dar , den der Codeabschnitt erfüllen muss.

Früherkennung von Problemen im Entwicklungszyklus

Unit-Tests decken Probleme frühzeitig im Entwicklungszyklus auf . Dies umfasst sowohl Fehler in der Implementierung des Programmierers als auch Mängel oder fehlende Teile der Spezifikation für die Einheit. Das Schreiben eines umfassenden Testsets zwingt den Autor, Eingaben, Ausgaben und Fehlerbedingungen gründlich zu durchdenken und somit das gewünschte Verhalten der Einheit präziser zu definieren. [ 21 ]

Reduzierte Kosten

Die Kosten für das Auffinden eines Fehlers vor Beginn der Programmierung oder während der ersten Codephase sind deutlich geringer als die Kosten für dessen spätere Erkennung, Identifizierung und Behebung. Fehler in veröffentlichtem Code können zudem kostspielige Probleme für die Endnutzer der Software verursachen. [ 22 ] [ 23 ] [ 24 Schlecht geschriebener Code lässt sich unter Umständen nicht oder nur schwer testen. Unit-Tests können Entwickler daher dazu anregen , Funktionen und Objekte besser zu strukturieren.

Häufigere Veröffentlichungen

Unit-Tests ermöglichen häufigere Releases in der Softwareentwicklung. Durch das Testen einzelner Komponenten isoliert können Entwickler Probleme schnell erkennen und beheben, was zu schnelleren Iterations- und Releasezyklen führt. [ 25 ]

Ermöglicht Code-Refactoring

Unit-Tests ermöglichen es dem Programmierer, Code später zu refaktorisieren oder Systembibliotheken zu aktualisieren und sicherzustellen, dass das Modul weiterhin korrekt funktioniert (z. B. im Rahmen von Regressionstests ). Dabei werden Testfälle für alle Funktionen und Methoden geschrieben , sodass Fehler, die durch Änderungen verursacht werden, schnell erkannt werden können.

Erkennt Änderungen, die einen Designvertrag verletzen könnten.

Unit-Tests erkennen Änderungen, die gegen einen Designvertrag verstoßen könnten .

Unsicherheit reduzieren

Unit-Tests können die Unsicherheit in den einzelnen Einheiten verringern und im Rahmen eines Bottom-up -Testansatzes eingesetzt werden . Indem man zuerst die einzelnen Programmteile und anschließend das Gesamtpaket testet, wird das Integrationstesting deutlich vereinfacht.

Dokumentation des Systemverhaltens

Manche Programmierer argumentieren, dass Unit-Tests eine Form der Code-Dokumentation darstellen. Entwickler, die erfahren möchten, welche Funktionalität eine Unit bietet und wie sie verwendet wird, können die Unit-Tests einsehen, um ein besseres Verständnis dafür zu erlangen. [ 26 ]

Testfälle können Merkmale verkörpern, die für den Erfolg einer Einheit entscheidend sind. Diese Merkmale können auf eine angemessene/unangemessene Verwendung einer Einheit sowie auf negative Verhaltensweisen hinweisen, die von der Einheit abgefangen werden sollen. Ein Testfall dokumentiert diese kritischen Merkmale, obwohl viele Softwareentwicklungsumgebungen nicht ausschließlich auf Code zur Dokumentation des Produkts in der Entwicklung setzen.

In manchen Prozessen kann das Schreiben von Tests und des zu testenden Codes sowie das damit verbundene Refactoring die formale Konstruktion ersetzen. Jeder Unit-Test kann als Konstruktionselement betrachtet werden, das Klassen, Methoden und beobachtbares Verhalten spezifiziert. [ 27 ]

Einschränkungen und Nachteile

Tests decken nicht jeden Fehler im Programm auf, da sie nicht jeden Ausführungspfad – außer in den trivialsten Programmen – auswerten können. Dieses Problem ist eine Obermenge des Halteproblems , welches unentscheidbar ist . Dasselbe gilt für Unit-Tests. Per Definition prüfen Unit-Tests zudem nur die Funktionalität der einzelnen Einheiten. Daher decken sie weder Integrationsfehler noch systemweite Fehler auf (z. B. Fehler in Funktionen, die von mehreren Einheiten ausgeführt werden, oder nicht-funktionale Testbereiche wie die Performance ). Unit-Tests sollten daher in Kombination mit anderen Softwaretestaktivitäten durchgeführt werden , da sie lediglich das Vorhandensein oder Fehlen bestimmter Fehler aufzeigen können; sie können jedoch nicht die vollständige Fehlerfreiheit beweisen. Um korrektes Verhalten für jeden Ausführungspfad und jede mögliche Eingabe zu gewährleisten und Fehler auszuschließen, sind andere Techniken erforderlich, insbesondere die Anwendung formaler Methoden , um zu beweisen, dass eine Softwarekomponente kein unerwartetes Verhalten aufweist.

Eine komplexe Hierarchie von Unit-Tests ist nicht gleichbedeutend mit Integrationstests. Die Integration mit peripheren Komponenten sollte in Integrationstests, nicht aber in Unit-Tests, berücksichtigt werden. Integrationstests basieren typischerweise immer noch stark auf manuellen Tests durch Menschen ; Tests auf hoher Ebene oder mit globalem Umfang lassen sich oft nur schwer automatisieren, sodass manuelle Tests häufig schneller und kostengünstiger erscheinen.

Softwaretests sind ein kombinatorisches Problem. Beispielsweise benötigt jede boolesche Entscheidung mindestens zwei Tests: einen mit dem Ergebnis „wahr“ und einen mit dem Ergebnis „falsch“. Daher benötigen Programmierer für jede geschriebene Codezeile oft drei bis fünf Zeilen Testcode. Dies kostet natürlich Zeit, und der Aufwand lohnt sich möglicherweise nicht. Es gibt Probleme, die sich überhaupt nicht ohne Weiteres testen lassen – beispielsweise nichtdeterministische Probleme oder solche, die mehrere Threads betreffen . Darüber hinaus ist der Code für einen Unit-Test genauso fehlerhaft wie der Code, den er testet. Fred Brooks zitiert in „Der Mythos des Mannmonats“ : „Geh niemals mit zwei Chronometern zur See; nimm einen oder drei mit.“ [ 28 ] (Wenn zwei Chronometer widersprüchliche Werte anzeigen, kann man nicht wissen, welcher korrekt ist.)

Schwierigkeiten bei der Durchführung realistischer und nützlicher Tests

Eine weitere Herausforderung beim Schreiben von Unit-Tests besteht darin, realistische und aussagekräftige Tests zu erstellen. Es ist notwendig, relevante Anfangsbedingungen zu schaffen, damit sich der zu testende Teil der Anwendung wie ein Teil des Gesamtsystems verhält. Werden diese Anfangsbedingungen nicht korrekt gesetzt, testet der Code nicht in einem realistischen Kontext, was den Wert und die Genauigkeit der Unit-Test-Ergebnisse mindert. [ 29 ]

Erfordert Disziplin während des gesamten Entwicklungsprozesses

Um die beabsichtigten Vorteile von Unit-Tests zu erzielen, ist während des gesamten Softwareentwicklungsprozesses eine strenge Disziplin erforderlich.

Erfordert Versionskontrolle

Es ist unerlässlich, nicht nur die durchgeführten Tests, sondern auch alle Änderungen am Quellcode dieser oder anderer Softwarekomponenten sorgfältig zu dokumentieren. Der Einsatz eines Versionskontrollsystems ist daher unerlässlich. Sollte eine spätere Version einer Komponente einen Test, den sie zuvor bestanden hat, nicht bestehen, kann die Versionskontrollsoftware eine Liste der seither vorgenommenen Quellcodeänderungen (falls vorhanden) bereitstellen.

Erfordert regelmäßige Überprüfungen

Es ist außerdem unerlässlich, einen nachhaltigen Prozess zu implementieren, der sicherstellt, dass Testfallfehler regelmäßig überprüft und umgehend behoben werden. [ 30 ] Wird ein solcher Prozess nicht implementiert und in den Arbeitsablauf des Teams integriert, entwickelt sich die Anwendung nicht mehr synchron mit der Unit-Test-Suite, was zu mehr falsch-positiven Ergebnissen führt und die Effektivität der Test-Suite verringert.

Einschränkungen für eingebettete Systemsoftware

Unit-Tests für Software eingebetteter Systeme stellen eine Herausforderung dar, da die Software auf einer anderen Plattform entwickelt wird als der, auf der sie später ausgeführt werden soll. Dies erschwert es, ein Testprogramm in der tatsächlichen Einsatzumgebung auszuführen, wie es bei Desktop-Programmen möglich ist. [ 31 ]

Einschränkungen beim Testen der Integration mit externen Systemen

Unit-Tests lassen sich in der Regel am einfachsten erstellen, wenn eine Methode Eingabeparameter und eine Ausgabe besitzt. Schwieriger gestaltet sich die Erstellung von Unit-Tests, wenn eine Hauptfunktion der Methode in der Interaktion mit externen Komponenten besteht. Beispielsweise könnte für eine Methode, die mit einer Datenbank arbeitet, die Erstellung eines Datenbank-Mockups erforderlich sein, welches wahrscheinlich nicht so umfassend ist wie die tatsächlichen Datenbankinteraktionen. [ 32 ]

Beispiele

JUnit

Nachfolgend finden Sie ein Beispiel für eine JUnit-Testsuite. Sie konzentriert sich auf die AdderKlasse. 

class Adder { public int add ( int a , int b ) { return a + b ; } }

Die Testsuite verwendet Assert -Anweisungen, um das erwartete Ergebnis verschiedener Eingabewerte der sumMethode zu überprüfen. 

import static org.junit.Assert.assertEquals ; import org.junit.Test ; public class AdderUnitTest { @Test public void sumReturnsZeroForZeroInput ( ) { Adder adder = new Adder (); assertEquals ( 0 , adder.add ( 0 , 0 ) ); }@Test public void sumReturnsSumOfTwoPositiveNumbers () { Adder adder = new Adder (); assertEquals ( 3 , adder . add ( 1 , 2 )); }@Test public void sumReturnsSumOfTwoNegativeNumbers () { Adder adder = new Adder (); assertEquals ( - 3 , adder . add ( - 1 , - 2 )); }@Test public void sumReturnsSumOfLargeNumbers () { Adder adder = new Adder (); assertEquals ( 2222 , adder . add ( 1234 , 988 )); } }

Als ausführbare Spezifikationen

Die Verwendung von Unit-Tests als Entwurfsspezifikation bietet einen entscheidenden Vorteil gegenüber anderen Entwurfsmethoden: Das Entwurfsdokument (die Unit-Tests selbst) kann zur Überprüfung der Implementierung verwendet werden. Die Tests werden nur dann erfolgreich sein, wenn der Entwickler eine Lösung gemäß dem Entwurf implementiert.

Unit-Tests bieten nicht die gleiche Zugänglichkeit wie diagrammatische Spezifikationen, beispielsweise UML- Diagramme. Sie können jedoch mithilfe automatisierter Tools aus den Unit-Tests generiert werden. Für die meisten modernen Programmiersprachen stehen kostenlose Tools zur Verfügung (üblicherweise als Erweiterungen für IDEs ). Kostenlose Tools, wie beispielsweise solche, die auf dem xUnit -Framework basieren, lagern die grafische Darstellung der Ansicht für den menschlichen Betrachter an ein externes System aus. [ 33 ]

Anwendungen

Extreme Programmierung

Unit-Tests sind die Grundlage des Extreme Programming ( EP) , das auf einem automatisierten Unit-Testing-Framework basiert . Dieses Framework kann entweder von einem Drittanbieter stammen, z. B. xUnit , oder innerhalb des Entwicklerteams entwickelt werden.

Extreme Programming nutzt Unit-Tests für die testgetriebene Entwicklung . Der Entwickler schreibt einen Unit-Test, der entweder eine Softwareanforderung oder einen Fehler aufdeckt. Dieser Test schlägt fehl, weil die Anforderung entweder noch nicht implementiert ist oder weil er absichtlich einen Fehler im bestehenden Code offenlegt. Anschließend schreibt der Entwickler den einfachsten Code, damit dieser Test und alle anderen Tests erfolgreich sind.

Der Großteil des Codes in einem System wird zwar durch Unit-Tests abgedeckt, jedoch nicht unbedingt alle Ausführungspfade. Extreme Programming (XP) fordert daher eine Strategie, bei der alles getestet wird, was potenziell Fehler verursachen kann, anstatt jeden Ausführungspfad zu testen. Dies führt dazu, dass Entwickler weniger Tests erstellen als bei klassischen Methoden. Das ist jedoch kein wirkliches Problem, sondern eher eine Feststellung der Tatsache, da klassische Methoden selten systematisch genug angewendet wurden, um alle Ausführungspfade gründlich zu testen. [ 34 ] XP erkennt an, dass Tests selten vollständig sind (da sie oft zu teuer und zeitaufwendig sind, um wirtschaftlich rentabel zu sein) und bietet Anleitungen, wie begrenzte Ressourcen effektiv eingesetzt werden können.

Entscheidend ist, dass der Testcode als erstklassiges Projektartefakt gilt und daher in der gleichen Qualität wie der Implementierungscode gepflegt wird, wobei jegliche Duplikate entfernt werden. Entwickler veröffentlichen den Unit-Test-Code zusammen mit dem zu testenden Code im Code-Repository. Die gründlichen Unit-Tests von Extreme Programming ermöglichen die oben genannten Vorteile, wie z. B. eine einfachere und sicherere Codeentwicklung und -refaktorisierung , eine vereinfachte Codeintegration, eine präzise Dokumentation und modularere Architekturen. Diese Unit-Tests werden zudem kontinuierlich als eine Art Regressionstest ausgeführt .

Unit-Tests sind auch für das Konzept des Emergent Design von entscheidender Bedeutung . Dieses entwickelt Software-Design iterativ durch kurze testgetriebene Entwicklungszyklen, die aus dem Schreiben eines Unit-Tests, dessen erfolgreichem Bestehen und dem anschließenden Refactoring bestehen. Unit-Tests bieten das Sicherheitsnetz für Regressionen, das kontinuierliches Refactoring sicher macht. [ 35 ]

Frameworks für automatisiertes Testen

Ein Framework für automatisiertes Testen bietet Funktionen zur Automatisierung der Testausführung und kann das Schreiben und Ausführen von Tests beschleunigen. Solche Frameworks wurden für eine Vielzahl von Programmiersprachen entwickelt .

Frameworks sind in der Regel Drittanbieterprodukte und werden nicht mit einem Compiler oder einer integrierten Entwicklungsumgebung (IDE) ausgeliefert.

Tests können auch ohne Framework geschrieben werden, um den zu testenden Code mithilfe von Assertions , Ausnahmebehandlung und anderen Kontrollflussmechanismen zu prüfen , das Verhalten zu verifizieren und Fehler zu melden. Manche argumentieren, dass Tests ohne Framework wertvoll sind, da die Einführung eines Frameworks eine gewisse Hürde darstellt und einige Tests besser sind als gar keine – sobald jedoch ein Framework vorhanden ist, lassen sich Tests leichter hinzufügen. [ 36 ]

In einigen Frameworks fehlen erweiterte Testfunktionen und müssen manuell codiert werden.

Unterstützung für Unit-Tests auf Sprachebene

Manche Programmiersprachen unterstützen Unit-Tests direkt. Ihre Grammatik erlaubt die direkte Deklaration von Unit-Tests ohne Import einer Bibliothek (weder einer Drittanbieterbibliothek noch einer Standardbibliothek). Darüber hinaus lassen sich die booleschen Bedingungen der Unit-Tests in derselben Syntax wie boolesche Ausdrücke im übrigen Code ausdrücken, beispielsweise wie bei `if` if- whileAnweisungen.

Zu den Sprachen mit integrierter Unterstützung für Unit-Tests gehören:

Zu den Sprachen mit Unterstützung für Standard-Unit-Testing-Frameworks gehören:

Einige Programmiersprachen bieten keine integrierte Unterstützung für Unit-Tests, verfügen aber über etablierte Unit-Test-Bibliotheken oder -Frameworks. Zu diesen Sprachen gehören:

Siehe auch

Referenzen

  1. ^ a b Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management . Wiley-IEEE Computer Society Press. S. 75. ISBN 978-0-470-04212-0Die
  2. ^ Amazon Web Services (AWS). (o. J.). Was ist Unit-Testing? Abgerufen am 2. Mai 2025 von [1] ( https://aws.amazon.com/what-is/unit-testing/ )
  3. ^ Benington, Herbert D. (1956). „Produktion großer Computerprogramme“. Proceedings des Symposiums über fortgeschrittene Programmiermethoden für Digitalrechner, Washington, DC, 28.–29. Juni 1956. Office of Naval Research, Department of the Navy: 15–28 .
  4. ^ a b Benington, HD (1. März 1987). „Produktion großer Computerprogramme (Nachdruck des Artikels von 1956 mit aktualisiertem Vorwort)“ . Proceedings of the 9th International Conference on Software Engineering . ICSE '87. Washington, DC, USA: IEEE Computer Society Press: 299–310 . ISBN 978-0-89791-216-7Die
  5. ^ Donegan, James J.; Packard, Calvin; Pashby, Paul (1. Januar 1964). „Erfahrungen mit dem Goddard-Computersystem während bemannter Raumfahrtmissionen“ . Proceedings der 19. ACM-Nationalkonferenz 1964. ACM '64. New York, NY , USA: Association for Computing Machinery. S.  12.101–12.108 . doi : 10.1145/800257.808889 . ISBN 978-1-4503-7918-2Die{{cite book}}:ISBN-/Datumsinkompatibilität ( Hilfe )
  6. ^ Zimmerman, Norman A. (26. August 1969). „Systemintegration als Programmierfunktion“ . Proceedings der 24. Nationalen Konferenz 1969. ACM '69. New York, NY, USA: Association for Computing Machinery. S.  459–467 . doi : 10.1145/800195.805951 . ISBN 978-1-4503-7493-4Die
  7. ^ MIL-STD-483 Militärstandard: Konfigurationsmanagementverfahren für Systeme, Ausrüstung, Munition und Computerprogramme . Verteidigungsministerium der Vereinigten Staaten. 31. Dezember 1970. S. Abschnitt 3.4.7.2. Der Auftragnehmer muss anschließend Softwareeinheiten codieren und testen sowie den Quell- und Objektcode und die zugehörigen Auflistungen jeder erfolgreich getesteten Einheit in die Entwicklungskonfiguration eintragen.
  8. ^ Tighe, Michael F. (1. Januar 1978). „Der Wert einer geeigneten Software-Qualitätssicherungsmethodik“ . ACM SIGMETRICS Performance Evaluation Review . 7 ( 3–4 ): 165–172 . doi : 10.1145/1007775.811118 . ISSN 0163-5999 . 
  9. ^ Gulati, Shekhar (2017). Java Unit Testing with JUnit 5: Test Driven Development with JUnit 5. Rahul Sharma. Berkeley, CA: Apress. S. 8. ISBN 978-1-4842-3015-2OCLC  1012347252 .​
  10. ^ Winters, Titus (2020). Softwareentwicklung bei Google: Lehren aus der Programmierpraxis . Tom Manshreck, Hyrum Wright (1. Aufl.). Sebastopol, CA: O'Reilly. ISBN 978-1-4920-8274-3OCLC  1144086840 .​
  11. ^ Beck, Kent (2002). Testgetriebene Entwicklung anhand von Beispielen . Addison-Wesley. ISBN 978-0321146533Die
  12. ^ System- und Softwareentwicklung – Vokabular . ISO/IEC/IEEE 24765:2010(E). 1. Dezember 2010. S.  1–418 . doi : 10.1109/IEEESTD.2010.5733835 . ISBN 978-0-7381-6205-8Die
  13. ^ Kaner, Cem (Mai 2003). „Was ist ein guter Testfall?“ (PDF) . STAR East : 2.
  14. ^ Gulati & Sharma 2017 , S. 133–137, Kapitel §7 JUnit 5 Erweiterungsmodell - Parametrisierter Test.
  15. ^ Kampmann, Alexander; Zeller, Andreas (Mai 2019). „Carving Parameterized Unit Tests“. 2019 IEEE/ACM 41st International Conference on Software Engineering: Companion Proceedings (ICSE-Companion) . S.  248–249 . doi : 10.1109/icse-companion.2019.00098 . ISBN 978-1-7281-1764-5Die
  16. ^ Burton, Ross (12. November 2003). „Subverting Java Access Protection for Unit Testing“ . O'Reilly Media, Inc. Abgerufen am 12. August 2009 .
  17. ^ van Rossum, Guido; Warsaw, Barry (5. Juli 2001). „PEP 8 – Style Guide for Python Code“ . Python Software Foundation . Abgerufen am 6. Mai 2012 .
  18. ^ Newkirk, James (7. Juni 2004). „Testing Private Methods/Member Variables - Should you or shouldn't you“ . Microsoft Corporation . Abgerufen am 12. August 2009 .
  19. ^ Stall, Tim (1. März 2005). „Wie man private und geschützte Methoden in .NET testet“ . CodeProject. Archiviert vom Original am 3. September 2009. Abgerufen am 12. August 2009 .
  20. ^ a b Hamill, Paul (2004). Unit Test Frameworks: Tools for High-Quality Software Development . O'Reilly Media, Inc. ISBN 9780596552817Die
  21. ^ Gren, Lucas; Antinyan, Vard (August 2017). Zum Zusammenhang zwischen Unit-Tests und Codequalität . 43. Euromicro-Konferenz über Software-Engineering und fortgeschrittene Anwendungen (SEAA). S.  52–56 . doi : 10.1109/seaa.2017.36 . Abgerufen am 16. Mai 2026 .
  22. ^ Boehm, Barry W .; Papaccio, Philip N. (Oktober 1988). „Understanding and Controlling Software Costs“ (PDF) . IEEE Transactions on Software Engineering . 14 (10): 1462–1477 . Bibcode : 1988ITSEn..14.1462B . doi : 10.1109/32.6191 . Archiviert vom Original (PDF) am 9. Oktober 2016. Abgerufen am 13. Mai 2016 .
  23. ^ „Früh und oft testen“ . Microsoft.
  24. ^ „Beweisen Sie, dass es funktioniert: Die Verwendung des Unit-Test-Frameworks für Softwaretests und -validierung“ . National Instruments . 21. August 2017.
  25. ^ Erik (10. März 2023). „Du weißt immer noch nicht, wie man Unit-Tests durchführt (und dein Geheimnis ist bei mir sicher)“ . Stackify . Abgerufen am 10. März 2023 .
  26. ^ Stocker, Karsten; Washizaki, Hironori; Fukazawa, Yoshiaki (März 2017). „Die Lücke zwischen Unit-Test-Code und Dokumentation schließen“. 2017 IEEE International Conference on Software Testing, Verification and Validation Workshops (ICSTW) . S.  304–308 . doi : 10.1109/icstw.2017.56 . ISBN 978-1-5090-6676-6Die
  27. Nassif , M.; Hernandez, Alexa; Sridharan, Ashvitha; Robillard, M. (2022). „Generierung von Unit-Tests für die Dokumentation“. IEEE Transactions on Software Engineering . 48 (9): 3268–3279 . arXiv : 2005.08750 . Bibcode : 2022ITSEn..48.3268N . doi : 10.1109/TSE.2021.3087087 .
  28. ^ Brooks, Frederick J. (1995) [1975]. Der Mythos des Mannmonats . Addison-Wesley. S.  64. ISBN 978-0-201-83595-3Die
  29. ^ Tiwari, Deepika; Monperrus, Martin; Baudry, Benoit (November 2024). „Mimicking Production Behavior With Generated Mocks“. IEEE Transactions on Software Engineering . 50 (11): 2921–2946 . Bibcode : 2024ITSEn..50.2921T . doi : 10.1109/tse.2024.3458448 . ISSN 2326-3881 . 
  30. ^ daVeiga, Nada (6. Februar 2008). „Code ändern ohne Angst: Nutzen Sie ein Regressionssicherheitsnetz“ . Abgerufen am 8. Februar 2008 .
  31. ^ Kucharski, Marek (23. November 2011). „Making Unit Testing Practical for Embedded Development“ . Abgerufen am 20. Juli 2020 .
  32. ^ „Unit-Tests und Datenbanken“ . Abgerufen am 29. Januar 2024 .
  33. ^ GeeksforGeeks. (2024). Unit Testing . Abgerufen am 2. Mai 2025 von [2] ( https://www.geeksforgeeks.org/unit-testing-software-testing/ )
  34. ^ Beck, Kent (Oktober 1999). „Extreme Programming Explained: Embrace Change“ . Computer . 32 (10): 70–76 . doi : 10.1109/52.844236 (inaktiv am 15. Mai 2026) . Abgerufen am 7. Mai 2026 .{{cite journal}}: CS1 Wartung: DOI inaktiv seit Mai 2026 ( Link )
  35. ^ Fucci, Davide; Erdogmus, Hakan; Turhan, Burak; Oivo, Markku; Juristo, Natalia (2017). „ Eine Analyse des testgetriebenen Entwicklungsprozesses: Spielt es wirklich eine Rolle, ob man zuerst oder zuletzt testet?“ IEEE Transactions on Software Engineering . 43 (7): 597–614 . doi : 10.1109/tse.2016.2616877 . ISSN 1939-3520 . Abgerufen am 25. Mai 2026 . 
  36. ^ Bullseye Testing Technology (2006–2008). „Intermediate Coverage Goals“ . Abgerufen am 24. März 2009 .
  37. ^ „Unit-Tests – D-Programmiersprache“ . D-Programmiersprache . D Language Foundation . Abgerufen am 5. August 2017 .
  38. ^ Steve Klabnik und Carol Nichols, mit Beiträgen der Rust-Community (2015–2023). „How to Write Tests“ . Abgerufen am 21. August 2023 .
  39. ^ „Crystal Spec“ . crystal-lang.org . Abgerufen am 18. September 2017 .
  40. ^ „Testen – Die Programmiersprache Go“ . golang.org . Abgerufen am 3. Dezember 2013 .
  41. ^ „Unit-Tests · Die Programmiersprache Julia“ . docs.julialang.org . Abgerufen am 15. Juni 2022 .
  42. ^ Python-Dokumentation (2016). „unittest – Framework für Unit-Tests“ . Abgerufen am 18. April 2016 .
  43. ^ Welsh, Noel; Culpepper, Ryan. „RackUnit: Unit Testing“ . PLT Design Inc. Abgerufen am 26. Februar 2019 .
  44. ^ Welsh, Noel; Culpepper, Ryan. „RackUnit Unit Testing package part of Racket main distribution“ . PLT Design Inc. Abgerufen am 26. Februar 2019 .
  45. ^ „Minitest (Ruby 2.0)“ . Ruby-Doc.org.
  46. ^ Sierra, Stuart. „API für clojure.test - Clojure v1.6 (stabil)“ . Abgerufen am 11. Februar 2015 .
  47. ^ „Pester Framework“ . GitHub . Abgerufen am 28. Januar 2016 .

Weiterführende Literatur

  • Feathers, Michael C. (2005). Effektives Arbeiten mit Legacy-Code . Upper Saddle River, NJ: Prentice Hall Professional Technical Reference. ISBN 978-0131177055Die
  • Gulati, Shekhar; Sharma, Rahul (2017). Java Unit Testing with JUnit 5 . Apress .