Anzeige von Methoden/Eigenschaften ohne Testabdeckung

[Sten Schmidt]

Feature-Request: Anzeige von Methoden/Eigenschaften ohne Testabdeckung

Mantis-Link: http://bug.access-codelib.net/view.php?id=87

Es wäre schön, wenn im Dialog "Testmethoden einfügen" die Methoden / Eigenschaften die bereits mit einem oder mehreren Tests versehen sind anders dargestellt oder markiert werden. Ggf. auch als CheckBox "Nur Methoden / Eigenschaften ohne Test anzeigen".

Denkbar wäre aber auch ein neuer Dialog, mit dem man die Testabdeckung einzelner Module/Klassen darstellen kann.

Die Idee finde ich gut - nur wie stellt man fest, ob es bereits Tests für eine Methode gibt?
Nur anhand der Bennenung der Test-Methoden oder soll der Testcode nach Codeteilen durchsucht werden, die diese Methoden aufrufen.
Ist eine Methode in Verwendung, wenn sie in einem Test (über eine andere Methode) genutzt aber nicht direkt vom Test aufgerufen wird?

Anm.: das erinnert mich an NCrunch bzw. dotCover.

[Sten Schmidt]

Nur als Idee:

Wenn AccUnit die Tests abarbeitet, muss es ja die Methoden/Funktionen aufrufen und könnte sich diese merken.
Wenn dabei eine Methode/Funktion mehrfach aufgerufen wird, dann wird einfach die Anzahl um 1 hochgezählt (auf der Merkliste).

D.h. die "Statistik der Testabdeckung" könnte man Erstellen / Aktualisieren, wenn AccUnit alle Tests durchläuft.

[Josef Pötzl]

Ein Beispiel:

Klasse XYZ:

Code: Alles auswählen

Public Sub Proc1()
  Call Proc2()
  ...
End Sub

Public Sub Proc2()
  ...
End Sub

Angenommen es gibt einen Test für "Proc1" - ist nun auch "Proc2" getestet?

Wenn AccUnit die Tests abarbeitet, muss es ja die Methoden/Funktionen aufrufen und könnte sich diese merken.

AccUnit muss die zu testenden Methoden nicht ausführen. Es werden nur die Methoden aus den Testklassen aufgerufen.

[Sten Schmidt]

@Josef: Hab das falsche Forum erwischt, kannste den Thread verschieben?

Ich würde sagen das "Proc2()" nur dann als getestet gilt, wenn es einen eignen Test dazu gib. Also vom Gefühl her ehr ein nein. Aber es ist tatsächlich eine interessante Frage.

/edit (Josef): Thema verschoben und Prozedurnamen angepasst

[Josef Pötzl]

Hallo!

Folgende Variante kann keinesfalls schaden:
Anzeigen, ob es ein bestimmte Testemethode (in Abhängigkeit der Eingaben von "getesteter Zustand" und "erwartetes Verhalten") bereits existiert.

Für die anderen Prüfungen müssten wir eigentlich den Code durchsuchen.
Zuerst dachte ich noch an folgende Variante: Unter Voraussetzung, dass die Benennungsregel eingehalten wird, könnte man nach den vorhandenen Testmethoden suchen.
Das ist aber auch zu unsicher, da jemand Prozedurnamen gleich anfangen lssen könnte.
Beispiel:

Code: Alles auswählen

Public sub ProcXyz()
...
End sub

Public sub ProcXyz_Erweiterung1()
...
End Sub

Testmethode:

Code: Alles auswählen

public sub ProcXyz_Erweiterung1_TestA()
...
End Sub

Somit müsste man bei der Suche nach "ProcXyz_" auch noch prüfen, ob diese Testmethdoe nicht für ProcXyz_Erweiterung1 usw. sein könnte.

Das sind mir etwas zu viele Möglichkeiten. Denn ein Feature einbauen, das nur mit etwas Glück funktioniert, finde ich nicht besonders toll.

=> Wenn man dieses Feature nutzen will, bleibt meiner Ansicht nach nichts anderes übrig, als nach der Verwendung der Methoden im Code zu suchen.
Für diese Variante habe ich wieder eine Frage:

Code: Alles auswählen

public sub ProcXyz_InitWithString_ReturnIrgendwas()

    ...
    TestObject = New UrsuperKlasse
    TestObject.Init "abc"
    Actual = TestObject.ProcXyz(123)
    ...

End Sub

Wurde mit dieser Methode nun auch Init getestet?

mfg
Josef

[Sten Schmidt]

Zuerst dachte ich noch an folgende Variante: Unter Voraussetzung, dass die Benennungsregel eingehalten wird, könnte man nach den vorhandenen Testmethoden suchen. Das ist aber auch zu unsicher, da jemand Prozedurnamen gleich anfangen lssen könnte.

Das stimmt, ich merke es in der Praxis bei mir selbst, man benennt die Methoden auch gerne mal um, oder Arbeitet gerade an einem anderen Rechner und hat dort die "Neusten" Benennungsregeln noch nicht nachgetragen. Das fällt aus.

Das sind mir etwas zu viele Möglichkeiten. Denn ein Feature einbauen, dass nur mit Glück funktioniert, finde ich nicht besonders toll.

ACK

=> Wenn man dieses Feature nutzen will, bleibt meiner Ansicht nach nichts anderes übrig, als nach der Verwendung der Methoden im Code zu suchen.

Ja genau. Suche nach allen Vorkommnissen von ProcXyz(), und nur dann "mitzählen" wenn sich die Fundstelle in einer Testklasse

a) befindet und
b) Diese Testklasse in der TestClassFactory aktiviert ist.

Oder so ähnlich...

Für diese Variante habe ich wieder eine Frage:

Code: Alles auswählen

public sub ProcXyz_InitWithString_ReturnIrgendwas()

    ...
    TestObject = New UrsuperKlasse
    TestObject.Init "abc"
    Actual = TestObject.ProcXyz(123)
    ...

End Sub

Wurde mit dieser Methode nun auch Init getestet?

Eigentlich das gleiche wie bei Funktionen oder Subs. Ich würde das als "indirekt getestet" ansehen.
Der Test schlägt ja nur Fehl wenn die Init-Methode

a) eine Exception wirft oder
b) die Methode ProcXyz von dem Init-Parameter abhängig ist.

Wenn es für ProcXyz egal ist welchen Parameter Init hat (weil er z.B. nur nicht Null sein durfte) dann wäre ja die Aussagesicherheit der Tests verringert.

Vieleicht sollten wir mal Schauen wie es das NCrunch umgesetzt hat.

[Josef Pötzl]

Code: Alles auswählen

TestObject.Init "abc"
Actual = TestObject.ProcXyz(123)

Wenn hier nur ProcXyz als getestet gelten soll: wie soll man das per Code erkennen? Künstliche Intelligenz zu programmieren übersteigt meine Programmierkenntnisse.

NCrunch prüft, ob der Code bei Tests durchlaufen wird. Es erkennt somit auch indirekt genutzte Prozeduren.

mfg
Josef

[Paul Rohorzka]

Hallo!

Man könnte natürlich schon einige Heuristiken einsetzen (wie Zuweisung an eine Variable namens Actual, ein Kommentar ' Act oder ' Test vor oder in der Zeile, die letzte Zeile vor dem ersten Assert, ...). Solche Versuche würden IMHO aber immer nur eine eher fragwürdige Aussagekraft besitzen.

Wenn ich - egal nach welcher Methode - erkenne dass für eine Methode kein Test existieren dürfte? Dann dürfte die Methode nicht getestet sein. Ok, da ist was zu tun. Wenn aber für eine Methode ein Test gefunden wird, dann habe ich immer noch keine Aussage darüber ob diese Tests ausreichend sind (was immer das bedeutet).

[Josef Pötzl]

Hallo!

Im Prinzip müsste man die Prozeduraufrufe mitprotokollieren und hätte dann die Information, welche Prozeduren in Tests durchlaufen wurden. => Man findet jene, die in keinem einzigen Test genutzt werden. So ähnlich läuft es zumindest bei NCrunch bzw. dotCover.

Ich habe allerdings keine Ahnung, wie man machen könnte. Nur die verwenden Prozeduren im Code suchen, sagt nur aus, welche Prozeduren man explizit nutzt. Diese Aussage bringt mir persönlich aber auch nicht viel.
Mit NCrunch bzw. dotCover erhalte ich eine besser nutzbare Information: ich sehe nämlich im Code, welche Codezeilen nicht durch Tests abgedeckt sind.

[FireWalkerHH]

Hallo zusammen!

Ein Feature zu haben, das einem anzeigt für welche Methoden noch kein Test besteht kann durchaus sinnvoll sein. Aber zu wissen durch wie viele Tests eine Methode abgedeckt wird ist, glaube ich, nicht sehr Aussagekräftig. Es sei den man bekommt es so hin wie in NCrunch, das einem genau anzeigt welche Codezeilen nicht von einem Test berührt werden. Obwohl diese Anzeige nichts über die Qualität der Tests aussagt, wie Paul schon schrieb.

Gruß,
Thomas