Diskussion:Modultest

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Modultest“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen, und unterschreibe deinen Beitrag bitte mit oder --~~~~.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Zum Archiv

Wie wird ein Archiv angelegt?

Auf dieser Seite werden Abschnitte automatisch archiviert, wenn sie mit {{Erledigt|1=--~~~~}} markiert sind und ihr jüngster signierter Beitrag mehr als 30 Tage zurückliegt.

Kürzen und strukturieren

Masse != Klasse.
Die beiden Absätze über Einsatz im Automotive Bereich und über Fluxtests sind Zusatzinformationen und gehören in einen eigenen Bereich, z.B. "Anwendungsbeispiele".
Jemand, der nur schnell erfahren will, was ein Modultest IST, verschwendet am Lesen solcher Passagen nur seine Zeit. Ich änder das mal :-) Anmerkung: Absolut richtig!!!!!!!!! (nicht signierter Beitrag von 62.154.197.162 (Diskussion) 16:37, 4. Nov. 2010 (CET))

---

Schade, dass nicht tiefergehend auf Unit-Tests eingegangen wird (weder hier, noch bei "CppUnit" ode "JUnit"), mit Beispielen und zu empfehlenden Übergabewerten (natürlich abstrakt).

Hallo, Unit Test ist schon der richtige Ausdruck. Mit der Unit ist die Einheit(=Unit) eines Codefragmentes gemeint, und nicht ein "Modul" das eine Aggregation dessen darstellt.

Ich wünsche mir hier auch ein paar mehr Details zur Umsetzung von Unit Tests: Was ist so besonders an der Umsetzung, was muss beachtet werden und welche Vorgehensweise sollte man befolgen? Ich denke hier besonders an Prüfungen (Asserts) und wie Fehler bewußt hevorgerufen werden können. Denn es geht ja nicht ausschließlich darum gültige Werte zu erhalten, sondern auch bewußt darum Fehler zu provozieren (z.B. mittels ungültigen Parametern). Erst dadurch kann man sicherstellen, dass ein Programmteil robust genug ist, um auch mit kritischen Zuständen zurechtzukommen.

Gute Idee, ich fang mal an. Also ein Ansatz ist, für jeden Fehler, der in der Software aufgetreten ist, einen Unit-Test zu schreiben. Und den Fehler natürlich zu fixen :-) Damit ist dann sichergestellt, dass so etwas eben nicht nocheinmal auftaucht.
Man kann sich auch vorher Gedanken machen, um zum Beispiel auf Grenzwerte und Kombinationen von Unit-Testszenarien zu kommen. Aus Aktivitätsdiagrammen lassen sich gute Testfälle ableiten. Vorher ist natürlich besser als nachher.

Dann sammeln wir mal Stoff. Je nach Testverfahren (White-Box-Test oder Black-Box-Test) kann ich auch explizit aus dem Code kritische Programmgrenzen ermitteln und diese explizit Testen. Für das Finden von Laufzeitfehlern innerhalb von Modulen gibt es mittlerweile auch effiziente Werkzeuge wie Polyspace, die hier automatisch Testen und die Robustheit der Software erhöhen. Wenn Anforderungen bis auf Units heruntergebrochen werden, sollten auch hier die Grenzen für die Unit-Tests herausfallen. Denn dann sollte das Verhalten der Unit im Grenzbereich genau definiert sein. --W.amadeus 18:28, 1. Feb 2006 (CET)

Zu den Unit-Tests gehört auch ein ordentliches Vorgehen. Die Unit Tests sollten regeläßig vor jedem Build ausgeführt werden. Ausserdem ist es eine gute Angewohnheit seinen Code vor dem Einchecken ins Repository mit einer lokalen Ausführung aller Unit-Tests zu prüfen. Damit kann man unnötige Fehlschläge beim zentralen Build verhindern. Es gibt übrigens auch Tools, die die Qualität der Tests selbst überprüfen, in dem sie die Bedingungen verändern.

Definitionen

(Kann man die Definitionen in den Artikel einarbeiten?)

Unit: Einzelne Funktion in einem Modul (z.B. C- Funktion). Im Sinne des Testes ist die Unit die kleinste Einheit, die getestet werden kann. Teile der Unit kann man nicht mehr vernünftig testen.

Modul: Abgegrenzter Programmteil mit relativ kleiner Schnittstelle (kann z.B. in einer C- Datei festgehalten sein), enthält mehrere Units.

Unit- Test: Test der einzelnen C- Funktion

Modul- Test : Test eines Moduls. Dabei können sowohl einige oder alle Units als auch die Schnittstellen zwischen den Units getestet werden.

Du schreibst "Teile der Unit kann man nicht mehr vernünftig testen". Und ob! Ein Programm besteht aus Projektdatei (*.dpr), [blubb...blubb], und Units (*.pas), die die Groß- bzw. Hauptteile deines Programmes beinhalten. Außerdem ist eine Unit keine Funktion ;). Oder meinst du andere Units wie z. B. die "Vorinstallierten" :?... MfG -- Wiki 1703 21:17, 30. Jul. 2008 (CEST)

Hallo Wiki 1703! Du scheinst dich hier nur auf die Sprache Object Pascal mit Delphi zu beziehen. Die Wörter Modultest und Unit-Test sind aber viel allgemeiner zu verstehen und beziehen sich auf sämtliche Softwareentwicklung mit beliebigen Prgrammiersprachen. Die Module in Object Pascal heißen zwar auch Units, die kleinste Einheit zu testenden Codes im Sinne des automatisierten Testens heißt ebenfalls Unit. Bitte nicht verwechseln!--HB Jepsen (Diskussion) 11:45, 19. Mär. 2012 (CET)

überarbeiten

Nach dem Lesen des Artikels ist man genauso schlau wie vorher. Da wird vieles ohne Zusammenhang angerissen. Übrigens, was ist ein Fluxtest? --Avron 13:59, 16. Jan. 2008 (CET)

Rubybeispiel sinnlos

Ich habe keinen Plan was dort passiert, ohne Erklärungen wertlos. Zudem wird noch ein Framework verwendet das nicht erklärt wird. Weg mit dem Beispiel oder nehmt was breiter bekannt ist wie JUnit,... (nicht signierter Beitrag von 84.164.138.103 (Diskussion) 09:06, 3. Mär. 2012 (CET))

Habs durch ein Java Beispiel ersetzt. Ist denke ich auch für Leute ohne Java Kenntnisse weit besser lesbar als das Rubybeispiel davor.--Sebastian.Dietrich ✉ 12:25, 3. Mär. 2012 (CET)

'Isolierung' von Testobjekten

Zur Info: Eine Diskussion fand in diesem [1] BNR statt.--VÖRBY (Diskussion) 10:08, 6. Aug. 2013 (CEST)

Unter Modultest#Isolierung von Testobjekten finden sich noch immer Bezeichnungen für Hilfsobjekte, die wohl i.Z. mit OO-Modultests unter Verwendung bestimmter Mocking Frameworks (und evtl. auf Fowler zurückgehend) gebräuchlich sind. Das sind aber Spezialfälle, die besser bei Mock-Objekt erläutert werden sollten. Dafür ist die grundsätzliche Unterscheidung in Stub und Driver nicht erwähnt. In Diskussion:Mock-Objekt#Stub vs Driver wurden diese Sachverhalte beschrieben, es gab aber leider noch kein Feedback. Deshalb HIER dieser Hinweis. --VÖRBY (Diskussion) 11:59, 9. Jun. 2017 (CEST)

Kein Feedback; dann möchte ich das (siehe Entwurf) entsprechend anpassen. --VÖRBY (Diskussion) 15:31, 13. Jun. 2017 (CEST)

Modultest ist nicht nur ein White-Box-Test

Meiner Meinung nach ist Modultest kein White-Box-Test, wie es in diesem Artikel behauptet wird.

Ein Modultest ist nach meinem Verständnis prinzipiell ein Black-Box-Test, da Eingabewerte definiert werden und die (vom Modul) erhalteten Ergebnisse mit Erwartungswerten verglichen werden. Der Quellcode muss dem Tester nicht interessieren.

Ein White-Box-Test wird doch erst daraus, wenn man prüft welche Anweisungen/Pfade/Bedingungen/... während des Tests durchlaufen wurden. Grundsätzlich prüft man ja aber bei einem Modultest erst einmal nur "den Vertrag und nicht die Algorithmen". (nicht signierter Beitrag von 84.155.219.168 (Diskussion) 16:06, 11. Okt. 2013 (CEST))

BlackBox ist er auf jeden Fall nicht, da das Modul (= die Klasse) eingesehen werde muss um zu erkennen, wie man sie testet (d.h. ihre public Methoden). Aber natürlich hast du recht, es wird der Contract getestet und nicht die Implementierung - aber eben der Contract von Bestandteile des Moduls - und die muss man daher kennen. mMn fallen Modultests daher eher unter GrayBox Testing. --Sebastian.Dietrich ✉ 18:29, 11. Okt. 2013 (CEST)

Ich denke, es kommt hier nicht so sehr darauf an, ob man mit oder ohne Kenntnis des Inhalts eines 'Moduls' testet - es geht i.W. darum, dass die Details eines Moduls getestet werden - mit verschiedensten Testarten (s.a. Softwaretest#Klasifikation für Testarten). Zum Kriterium Black/White passt da wohl in erster Linke 'White', aber 'Black' muss nicht ausgeschlossen werden. Die Aussage zu 'White-Box' ist deshalb nicht so absolut zu vestehen und ist auch mit "oft" umschrieben, könnte aber vielleicht besser formuliert werden. --VÖRBY (Diskussion) 17:24, 14. Okt. 2013 (CEST)

Ergänzung: Bei 84.155.219.168 dürfte ein Misverständnis vorliegen: Testarten sind keine disjunkten Begriffe, sondern leiten sich aus Kriterien ab, nach denen man Tests kategorisieren kann. So muss nicht jeder Whiteboxtest ein Anweisungsüberdeckungstest sein, umgekehrt i.d.R. schon.

Noch zu 'Greyboxtest': Dieser Begriff hängt lediglich mit der Testmethodik zusammen (testgetriebene Programmierung) und meint etwas anderes, nämlich dass der SW-Entwickler den Test selbst spezifiziert. Black oder White dagegen sind disjunkte 'Mengen', sie legen fest, ob ein Test ohne oder mit Kenntnis der genauen Spezifikation (meist des Codes) definiert wird/wurde, grey gibts da eigentlich nicht. --VÖRBY (Diskussion) 09:30, 15. Okt. 2013 (CEST)

Heutige Erweiterungen

Hi, @MovGPO. Ich denke, Du bist hier [2] übers Ziel hinausgeschossen. Der Artikel soll lt. Titel nur 'Modultests' behandeln und erklären. Die Synonymbezeichnung 'Komponententest' hast Du entfernt, dafür aber viele Testarten aufgeführt, die oft keine Tests 'elementarer Units' sind, sondern auf andere Testobjekte ausgerichtet, z.B. testet der End-to-End-Test nach Deinem Text "das Gesamtsystem". Ein derartiger Überblick über Testarten findet sich in Softwaretest, ggf. mit Link auf Einzellemmata. Ggf. kann man das DORT erweitern oder ergänzen - inkl. Deiner Quelle. Zusätzliche Beschreibungen an anderen Orten sind Redundanz oder ggf. auch Inkonsistenz. --VÖRBY (Diskussion) 16:53, 13. Mär. 2017 (CET)

Ich fürchte, mit der einfachen Verschiebung nach Softwaretest ist das nicht getan. Dort werden Testarten bereits behandelt - und zum Teil anders beschrieben. Deine Überschrift "Klassifikation nach Testumfang" ist zumindest begrifflich ziemlich dasselbe wie "Art und dem Umfang des Testobjekts" in Softwaretest#Weitere Klassifikation für Testarten. Insofern sollte man auf jeden Fall bei disjunkten Klassifikationskriterien bleiben. Auf jeden Fall dürfen wir mit dieser Form den Leser nicht verwirren. --VÖRBY (Diskussion) 17:21, 13. Mär. 2017 (CET)

Nicht lexikalisch

Auch die neuesten Erweiterungen gehören nicht in ein Lexikon. Sie sind viel zu detailliert und haben den Charakter von Handlungsempfehlungen - die nicht in Wikipedia-Artikel gehören. Ich wollte dies (vor einem Revert) aber hier zunächst nochmal kommunizieren, damit auch andere User ihre Meinung dazu äußern können. --VÖRBY (Diskussion) 09:02, 3. Mai 2017 (CEST)

Statt auf diesen Disk-Beitrag einzugehen, wurden die fraglichen Texte nochmal erheblich erweitert. Das gehört nicht in ein Lexikon!!! Und ist 'keine Art', hier mitzuwirken. Und so ist das nun schon zum zweiten Mal (siehe vorherigen Disk-Abschnitt, ebenfalls ohne Antwort). Ich habe deshalb die letzten Änderungen (siehe [3]) revertiert. Weitere Aktionen bitte erst nach abschließender Diskussion. @Arilou, @Mussklprozz, @Sebastian.Dietrich u.a. Beobachter zum Lemma hier - wollt Ihr da bitte mal mit reinschauen? --VÖRBY (Diskussion) 16:31, 3. Mai 2017 (CEST)

Bin ganz deiner Meinung - das ist viel detailiert für WP --Sebastian.Dietrich ✉ 22:24, 5. Mai 2017 (CEST)

Sinn?

Was habe ich davon, zu wissen, dass mein Code stichprobenartig für bestimmte Einzelfälle funktioniert? Wäre es nicht sinnvoller, die Logik des Codes zu analysieren? -- Mfnalex (Diskussion) 22:37, 17. Okt. 2018 (CEST)

'Stichprobenartig' ist im Artikel auf die dem Modultest nachgelagerten Teststufen (~Integrationstest) bezogen und genügt auch, weil/wenn die 'Units' ausführlich getestet wurden. Die 'Logik des Codes', die man eigentlich schon im 'Statischen Test' (siehe Softwaretest#Analytische Maßnahmen analysiert, wird durch Testfälle in 'dynamischen Tests' (wie dem Modultest) bestätigt. --VÖRBY (Diskussion) 10:21, 18. Okt. 2018 (CEST)

Nachteile - unklar

Der erste Spiegelpunkt kann m.E. entfallen, denn es ist selbstverständlich, dass bei Implementierung neuer Funktionalität auch neue Testfälle erforderlich sind.
Was mit dem dritten Punkt (IDE's) gemeint ist, ist unklar, möglicherweise soll gesagt werden, dass bei beabsichtigtem Entfernen von Funktionen (inkl. Testdaten) nicht klar ist, ob diese "anderweitig verwendet" werden. Das sollte aber bereits bei Erstellung der Änderungsvorgabe festgestellt sein und ist kein 'Nachteil von Modultests'VÖRBY (Diskussion) 17:20, 17. Jan. 2020 (CET)