Drei Test Axiome
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
- Antidecomposition Axiom
- eine adäquate Testabdeckung eines Moduls garantiert noch nicht die Abdeckung all der Teilmodule, die das Modul aufruft
- Beispiel: Verwendet libA libB, so sagt ein erfolgreicher Durchlauf der TestSuite von libA noch nichts über die Korrektheit von libB aus.
- Anticomposition Axiom
- adäquates Testen aller Teilmodule garantiert nicht automatisch adäquates Testen des Gesamtmoduls
- Beispiel: Verwendet eine Applikation libA, so sagt ein erfolgreicher Durchlauf der TestSuite der libA nichts über die Korrektheit der Applikation aus.
- Antiextensionality Axiom
- ein adäquater Test einer bestimmten Implementierung einer Spezifikation garantiert noch kein adäquates Testen für eine andere Implementierung derselben Spezifikation
- Beispiel: Die TestSuite für Motif ist nicht ausreichend um die Korrektheit von lesstif (eine OpenSource Implementierung von Motif) zu testen.
'adäquat' bezieht sich dabei auf ein vorher festzulegendes Maß der Testabdeckung.
Quelle: Robert Binder: Testing Object-Oriented Systems. Addison Wesley, 1999, ISBN 0201809389
F: Die obigen Axiome sind ja unmittelbar einsichtig. Kann man aber aus diesen theoretischen Formulierungen etwas für die praktische Arbeit Nützliches ableiten?
- Nun, z. B. dass keine noch so umfangreiche Suite von AkzeptanzTests in der Lage ist, KomponentenTests zu ersetzen - oder umgekehrt.
Ich glaube, dass das obige Beispiel direkt einsichtig ist und dass Formulierung und Einsatz obiger Axiome keinen Vorteil bringt.
Ich würde Dir ja zustimmen, die Realität lehrt uns allerdings anderes - tatsächlich ist diese Seite durch eine Diskussion auf dem XpForum motiviert worden, in der genau dieses Thema kontrovers diskutiert wurde.
Was mich an den Axiomen irritiert ist zweierlei:
- Einerseits spezialisieren sie ein allgemeines Prinzip (salopp: "Man kann vom einem Ganzen nicht unbedingt auf die Teile schließen und von den Teilen nicht unbedingt auf das Ganze"; 11 perfekte Fußballer müssen keine perfekte Mannschaft ergeben; die Eigenschaft eines Moleküls ergeben sich nicht aus den Eigenschaften seiner Atome; Synergieeffekte; ...). So stört mich diese Axiome ähnlich wie Unterprogramme, die mit CopyRapeAndPaste? an eine spezifische Teilsituation angepasst sind.
- Ich finde es schon wichtig, darauf hinzuweisen, dass diese Regeln auch für Tests gelten - sonst ist man leicht versucht, diese Situation für eine Ausnahme von der Regel zu halten.
- Andererseits erinnern mich diese Begriffsbildungen fatal an die Attitüden mancher Geisteswissenschaftler, die durch übermäßigen Gebrauch von Fremd- und Fachworten Wissenschaftlichkeit vortäuschen. Jeder kann "es genügt nicht, dass wir nur die einzelnen Teile Testen" verstehen, aber "auf Grund des Anticomposition Axioms ..." wird nicht so leicht verstanden. D.h. mich stören diese Begriffe ähnlich wie Code mit schlechter Lesbarkeit.
- Es ist aber wichtig, den Dingen Namen zu geben und ein gemeinsames Vokabular zu bilden (eine Motivation hinter der EntwurfsMuster-Bewegung) - verstoßen wir sonst nicht gegen die EinmalUndNurEinmal-Regel? Ich finde auch nicht, dass die Namen schlecht gewählt sind; sagen sie nicht genau das aus, was sie sollen (halt in Englisch)?
- Was mich an den Namen stört ist der Begriff Axiom. Die 3 "Axiome" sind eigentlich empirisch gewonnene Erfahrungswerte und daher (mehr oder weniger) beweisbar, ergo keine Axiome im mathematischen Sinne. -- JohannesLink
- Sie sind aber nicht im mathematischen Sinne beweisbar (was heißen würde, dass man sie aus anderen Axiomen ableiten kann), sondern werden (wegen der Erfahrungswerte) einfach als wahr angenommen.
- Was eher problematisch ist: ein Axiom ist 'unbestreitbar' wahr - wenn diese also wie von Helmut erklärt "direkt einsichtig" sind, ist der Begriff 'Axiom' wohl durchaus gerechtfertigt. Ich bin mir jedoch nicht sicher, dass die Breite Masse der SoftwareEntwickler hier zustimmen würde.
- RonJeffries scheint nach eigenen Aussagen z.B. beim Schreiben von KomponentenTests/InXp im wesentlichen das Antidecompositions Axiom zu ignorieren. Vielleicht setzt TestgetriebeneEntwicklung dieses Axiom (zumindest teilweise) außer Kraft? Möglicherweise gilt es auch nicht in gleichem Maße für BlackBoxTests? wie WhiteBoxTests? -- IljaPreuß
Ich denke, dass Software-Prinzipien wie "Wiederverwendbarkeit" und "Verständlichkeit" (und andere) sich nicht nur im Code niederschlagen müssen, sondern auch im Denken dahinter. Möglicherweise sind das sogar Werte einer Softwarephilosophie, die irgendwann auch gesellschaftliche Elemente beeinflussen könnte.
KategorieTesten
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 7. April 2005 9:44 (diff))