Diskussion:Modultest/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Modultest/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Modultest/Archiv/1#Thema_1

Mögliche Erweiterung prüfen

Unter Unit- Tests (völlig falsches Lemma) wurde was eingestellt. Wenn etwas integriert werden kann, dann möge sich bitte jemand drum kümmern. Ansonsten sollte der Artikel der jetzt ein Redirect ist gelöscht werden. -- Amtiss, SNAFU ? 19:28, 15. Apr 2006 (CEST)

ins Archiv:

Dieser Abschnitt kann archiviert werden. Hamburger 15:19, 22. Feb. 2012 (CET)

Verifikation...Korrektheit?

Ein Modultest dient zur Verifikation der Korrektheit? Das ist nach meiner Meinung nach ein wenig zu anmassend. Korrektheitsverifikation is ein Beweis, dass der Code sich 100%ig zu einer Spezifikation verhält. Das kann mir ein Unittest - bis auf triviale Programme - nicht zeigen. Terranic 08:58, 1. Feb. 2008 (CET)

Natürlich, ein Test dient der Fehlersuche, der Falsifizierung und nicht um die Korrektheit (Informatik) zu beweisen. --Steevie schimpfe hier :-) 12:03, 23. Apr. 2008 (CEST)

das stimmt natürlich --> habs ausgebessert --Sebastian.Dietrich 23:26, 1. Okt. 2009 (CEST)

ins Archiv:

Dieser Abschnitt kann archiviert werden. Hamburger 15:19, 22. Feb. 2012 (CET)

mir fehlt beim Thema Unit-Test die kritische Würdigung

• UnitTest braucht eine voll-objektorientierte Sprache, Unit Test mit VB6 z. B. ist krank und Zeitverschwendung.
• hat jemand schon mal den Produktivitätszuwachs / die Produktivitätsabnahme bei der Einführung von Unit Tests gemessen?
• Unit-Test bieten Scheinsicherheit. Jedesmal wenn ich eine Unit-Getestete Klasse ins Programm hänge finde ich reihenweise Fehler
• Das macht es dann schwierig, wenn man sagt Refractoring braucht die Sicherheit von Unit-Tests. (Unit Test können noch ein KLEIN wenig zusätzliche Sicherheit an schwierigen Stellen bieten, mehr aber nicht)
• Die Pflege von UnitTests ist aufwändig und ... wenn ich dran denke, dass an der Stelle der UnitTest erweitert gehört, denke ich auch daran, dass der Quellcode erweitert gehört. Vergesse ich beidest, dann scheppert es beim Kunden, weil UnitTest nicht aktuell.

vorstehender nichtsignierter Beitrag stammt von Benutzer:92.229.80.32. --Sebastian.Dietrich 23:31, 1. Okt. 2009 (CEST)

Danke für die konstruktive Kritik :-) Dazu ein paar Anmerkungen:

• UnitTests haben nix mit OO zu tun, das Prinzip beruht auf keinem der Prinzipien der OO. Ich hab z.B. (vor vielen Jahren) sehr gute Erfahrung mit UnitTests unter VB6 (mit einem selbstgeschriebenen UnitTest FW) gemacht. Hat unserem Projekt inkl. Entwicklung des Frameworks sicher wesentlich mehr gebracht als es gekostet hat.
• Ja da gibts Studien - auch dazu um wieviel weniger Bugs nachher drinnen sind, und um wieviel weniger Aufwand man daher in späteren Phasen (Test/Wartung) hat. Fazit: es zahlt sich aus. Werde die Studien im Artikel einbauen
• Scheinsicherheit - da gebe ich Dir vollkommen recht. Aber das gilt für alle Tests. Bei Tests muss immer auch die Testqualität bewertet werden. Das wäre bei Unittests u.A. die Codeabdeckung & noch einiges mehr.
• Refactoring braucht heutzutage nicht mehr unbedingt die Sicherheit von Unit-Tests. Automatische Refactorings, wie sie Eclipse bietet helfen da bzw. die Überlegung welche Refactorings potentiell gefährlich sind (d.h. Fehler beim Refactoring führen NICHT automatisch zu Compilefehlern)
• Ja die Pflege von UnitTests ist aufwändig. Die Pflege von Software ist aber immer aufwändig. Ohne Unit-Tests wesentlich aufwändiger als mit Unit-Tests (weitaus aufwändiger als die Erstellung von Unit-Tests).

Aber du hast Recht - all diese Punkte gehören in den Artikel eingebaut - immerhin werden sie oft als Gegenargument zu UnitTests und Pro "Weiterwursteln wie bisher" gebracht.

--Sebastian.Dietrich 23:41, 1. Okt. 2009 (CEST)

ins Archiv:

Dieser Abschnitt kann archiviert werden. Hamburger 15:19, 22. Feb. 2012 (CET)

Ungültiges Archivierungsziel

Die Zielangabe bei der automatischen Archivierung dieser Seite ist ungültig. Sie muss mit demselben Namen wie diese Seite beginnen. Wende dich bitte an meinen Besitzer, wenn das ein Problem darstellen sollte. ArchivBot 03:29, 23. Feb. 2012 (CET)

erledigtErledigt Harry8 21:07, 23. Feb. 2012 (CET)

Dieser Abschnitt kann archiviert werden. Harry8 21:07, 23. Feb. 2012 (CET)

Laufende Ausführung

Die laufende Ausführung sollte nicht Sinn und Zweck eines Modultests sein. Für diesen Zweck gibt es den so genannten Regressionstest. Hier wird etwas durcheinander geworfen. --85.158.196.15 14:23, 31. Mai 2011 (CEST)

Nein, Sie werfen etwas durcheinander. Modultest und Regressionstest schließen sich nicht aus. Das eine bezeichnet die Zugehörigkeit der Teststufe, das andere die Art den Test auszuführen. Für gewöhnlich kann (und sollte) man auf jeder Stufe Regressionstests durchführen --2001:16B8:2087:9E00:884:E1EE:5334:156D 09:48, 2. Mär. 2021 (CET)

Genau: In einem Modultest, egal wann er durchgeführt wird (in der Regel in der Teststufe 'Modultest' als frühe Teststufe), wird ein einzelnes Modul (isoliert) getestet. Wird dieser Test wiederholt, z.B. weil 'etwas' geändert/modifiziert wurde, dann ist das (so wie mit jeder anderen Testart auch) ein Regressionstest.

Archivierung dieses Abschnittes wurde gewünscht von: VÖRBY (Diskussion) 10:34, 3. Mär. 2021 (CET)