Konstanten testen

[monolith]

Hallo zusammen,

 

angenommen ihr habt eine öffentliche Klassenmethode geschrieben die nur eine in der selben Klasse definierte öffentliche Konstante mit dem Wert 12345 (Integer) zurückgibt (mag sinnbefreit klingen aber ist zum einen nur ein einfaches Beispiel, zum anderen kenne ich aber sogar ein Szenario in dem das sinnvoll ist).

Nun (wir machen hier kein TDD ) geht es ans Testschreiben. Wie würde der Test für die Methode bei euch aussehen? Würdet ihr den Rückgabewert der Methode direkt mit der Konstante vergleichen, oder würdet ihr den Rückgabewert der Methode mit 12345 (Integer) vergleichen? Ein Kollege von mir plädiert für letzteres. Sein Argument ist, mit dem Test möchte er sicherstellen, dass sich Verhalten nicht ungewollt ändert, was passieren könnte, wenn man versehentlich die Konstante in der Klasse verändert.

 

Wie seht ihr das?

[arlegermi]

Ich stimme deinem Kollegen zu. Wenn es darum geht, dass (blödes Beispiel) Pi bei euch immer genau 3 sein muss, dann hilft es dir nichts, zu testen, ob die Methode dir den Wert der Konstanten korrekt ausgibt. Wenn den jemand auf 3,14 geändert hat, bekommst du auch nur mit, ob die Methode den Wert nicht selber verändert.

Der Test ist aber in der Tat sehr merkwürdig. Eigentlich sollte so etwas durch (bspw.) CodeReview abgefangen werden.

Bearbeitet 9. Januar 2019 von arlegermi

[Whiz-zarD]

Welches Szenario soll es geben, wo so etwas sinnvoll ist? Die Konstante und die Methode sind redundant. Viel Schlimmer noch: Die Methode könnte sich ändern und beides läuft auseinander. Euer Test bekämpft also nur das Symptom und nicht die Ursache und die Ursache heißt "Redundanz".

[monolith]

vor einer Stunde schrieb Whiz-zarD:

Welches Szenario soll es geben, wo so etwas sinnvoll ist? Die Konstante und die Methode sind redundant. Viel Schlimmer noch: Die Methode könnte sich ändern und beides läuft auseinander. Euer Test bekämpft also nur das Symptom und nicht die Ursache und die Ursache heißt "Redundanz".

Das war das minimalste Demonstrationsbeispiel, das mir eingefallen ist. Daher auch meine Anmerkungen dazu. Alternativbeispiel: Eine Methode die den Wert der Konstante und sagen wir das aktuelle Jahr addiert und das Ergebnis zurückgibt. Würdest du dann bei dem Test des Ergebnis auf Gleichheit mit 12345 + AKTUELLE-JAHR oder auf KONSTANTE + AKTUELLES-JAHR prüfen?

Der Realweltbezug zum Rückgeben einer Konstante ist das Facade-"Pattern", das das PHP-Framework Laravel implementiert. Dort wird eine Klasse durch eine Art Wrapper um diese Klasse ersetzt. Der berücksichtigt  nur Methoden jedoch keine Klassenkonstanten, daher kann man über die Facade nicht direkt auf die Klassenkonstante zugreifen, wohl aber über den Umweg über die Methode. Bitte das jetzt nicht als Aufforderung zu einer Diskussion über diese Facade verstehen  Das wird sonst sehr Offtopic.

Bearbeitet 9. Januar 2019 von monolith

[Rienne]

Naja, sollte man prinzipiell nicht sowieso nur mittels Methoden (bzw. Getter und Setter) auf die Eigenschaften von Klassen/Objekten zugreifen können?

Ich persönlich würde ehrlich gesagt immer beides prüfen. Vor allem wenn es komplexer und unübersichtlicher wird und es vielleicht doch (unbeabsichtigt) zu einer Manipulation der Konstante kommt.

Bearbeitet 9. Januar 2019 von Rienne

[Whiz-zarD]

vor 53 Minuten schrieb monolith:

Alternativbeispiel: Eine Methode die den Wert der Konstante und sagen wir das aktuelle Jahr addiert und das Ergebnis zurückgibt. Würdest du dann bei dem Test des Ergebnis auf Gleichheit mit 12345 + AKTUELLE-JAHR oder auf KONSTANTE + AKTUELLES-JAHR prüfen?

Naja, ich würde mal hinterfragen, wieso dann die Konstante öffentlich sein muss, wenn der Grund für die Konstante die Benutzung in einer Methode ist? Was habe ich als Benutzer dieser Klasse davon? Muss ich als Benutzer die Konstante überhaupt kennen? Das Stichwort lautet hier "Information hiding". Wenn es also keinen Grund gibt, die Konstante öffentlich zu machen, dann sollte sie auch nicht öffentlich sein.

So, wie es für mich derzeit klingt, habt ihr keinen Anwendungsfall für die Konstante. Dann würde ich sie privat machen und dann erübrigt sich auch deine Frage.

Wenn du aber dennoch sowohl die Konstante als auch die Methode benötigst, was hindert dich daran, die beiden Tests durchzuführen, anstatt nur eine der beiden?

[monolith]

vor 19 Minuten schrieb Whiz-zarD:

Naja, ich würde mal hinterfragen, wieso dann die Konstante öffentlich sein muss, wenn der Grund für die Konstante die Benutzung in einer Methode ist?

Bist du zufällig im Hauptberuf Richter beim Bundesverfassungsgericht? Der umgeht das Entscheiden mancher richtungsweisender Urteile ja gerne mal mit salomonische Schläue.

Aaaaber um deine Frage zu beantworten: Der Wert der Konstante soll von außerhalb der Klasse zugreifbar sein. Daher sind sowohl die Konstante selber als auch die Methode öffentlich. Die Konstante wird innerhalb der Klasse per Direktzugriff verwendet; nur von außerhalb nicht.

Zitat

Was habe ich als Benutzer dieser Klasse davon? 

Innerhalb der Klasse greifst du direkt auf die Konstante zu. Das ist einfach eine Konstante ohne weitere Besonderheit. Die wird wie bei Konstanten üblich genutzt um nicht den selben, nicht aussagekräftigen, hardgecodeteten Integer-Wert an verschiedenen Stellen im Code ansprechen zu müssen.  Auch von außen benötigst du Zugriff auf den Wert hinter der Konstanten und willst aus den selben Gründen eben eine Konstante verwenden und nicht den hardgecodeten Wert. Leider kannst du das aber nicht aufgrund des Verwendeten Facade-Pattern (durch das Framework vorgegeben), daher bleibt dir als Alternative die Nutzung der Methode.

Zitat

Wenn es also keinen Grund gibt, die Konstante öffentlich zu machen, dann sollte sie auch nicht öffentlich sein.

In diesem Szenario gibt es dafür einen Grund.

Zitat

So, wie es für mich derzeit klingt, habt ihr keinen Anwendungsfall für die Konstante. Dann würde ich sie privat machen und dann erübrigt sich auch deine Frage.

Ja, wie gesagt, dass macht auch das Bundesverfassungsgericht gerne. Hilft aber in diesem Fall nicht weiter, da es hier um eine Grundsatzfrage geht und nicht darum wie in einem konkreten Anwendungsfall zu verfahren ist. Alle Beispiele dienen nur zur Erläuterung. Sie sind nicht Teil des eigentlichen Problems!

Zitat

Wenn du aber dennoch sowohl die Konstante als auch die Methode benötigst, was hindert dich daran, die beiden Tests durchzuführen, anstatt nur eine der beiden?

Wie meinst du das? Schlägst du vor, dass ich zwei Tests schreiben soll, je einen für die Methode und die Konstante? Das könnte ich tun. Wie würde der Test für die Konstante dann aussehen?

Bearbeitet 9. Januar 2019 von monolith

[Whiz-zarD]

vor 13 Minuten schrieb monolith:

Wie meinst du das? Schlägst du vor, dass ich zwei Tests schreiben soll, je einen für die Methode und die Konstante? Das könnte ich tun. Wie würde der Test für die Konstante dann aussehen?

Du hast doch gefragt, ob du nun die Konstante mit dem Ergebnis der Methode oder die Methode mit einem hartgecodeten Wert im Test vergleichen sollst. Wieso dann nicht beides? Du schreibst einfach zwei Tests. So gehst du sicher, dass sowohl die Kontante und Methode den selben Wert haben, als auch dass die Konstante sich nicht geändert hat.

Wobei ich immer noch nicht verstehe, wofür man die Konstante und die Methode braucht. Klingt eher nach einem Workaround und nicht nach einer sinnvollen technischen Umsetzung.

[monolith]

vor 43 Minuten schrieb Whiz-zarD:

Wieso dann nicht beides? Du schreibst einfach zwei Tests. So gehst du sicher, dass sowohl die Kontante und Methode den selben Wert haben, als auch dass die Konstante sich nicht geändert hat.

Ok.

Zitat

Wobei ich immer noch nicht verstehe, wofür man die Konstante und die Methode braucht. Klingt eher nach einem Workaround und nicht nach einer sinnvollen technischen Umsetzung.

Klar, das ist ein Workaround, der sich aus Besonderheiten eines Patterns ergibt. Ist aber nicht für die eigentliche Frage relevant. 

[Whiz-zarD]

vor 15 Minuten schrieb monolith:

Klar, das ist ein Workaround, der sich aus Besonderheiten eines Patterns ergibt. Ist aber nicht für die eigentliche Frage relevant.  

Mich interessiert es halt nur, wofür das gut sein sollte, da ich keinen sinnvollen Anwendungsfall konstruieren kann (höchstens eine Klasse, die ein Kreis darstellen soll und die Konstante Pi besitzt) und du behauptet, dass es sinnvoll sein kann. Workarounds sind für mich aber nicht sinnvoll, sondern ein Übel.

[monolith]

Für was genau kannst du keinen Anwendungsfall konstruieren? Für das 1. Konstante-Methode-Ding oder für 2. Nutzung der Konstante außerhalb der Klasse?

zu 1.: Wie gesagt das ist die Folge der Anwendung eines Patterns (Link zur offiziellen Doku aber weiß nicht wie hilfreich der ist: https://laravel.com/docs/5.7/facades ) das eine Klasse A nimmt und in eine Klasse B verpackt, wobei aber nur Methoden verpackt werden und keine Konstanten. Wenn du mit Klasse B arbeitest klappt zwar B.machWas() aber nicht B.KONSTANTE_XYZ weil nur Methodenaufrufe auf A (dynamisch, also zur Laufzeit) gemappt werden können. Daher als Workaround eine Methode die über B aufgerufen werden kann, eigentlich aber in A steht und somit auch Zugriff auf die Konstante hat. Klar das ist nicht optimal, die Programmiersprache scheint aber  keine Möglichkeit zu bieten dass auch Konstanten gemappt werden können. Der Mehrwert des Patterns wird als so groß bewertet, dass man den Nachteil in Kauf nimmt.

zu 2.: Den konkreten Anwendungsfall habe ich nicht im Kopf aber es ist ja denke ich klar das Szenarien denkbar sind in denen eine Konstante auch von außen zugreifbar sein sollte. Wäre kein solches Szenario denkbar wäre das Konzept öffentlich zugreifbarer Konstanten unsinnig.

 

Bearbeitet 10. Januar 2019 von monolith

[Rienne]

vor 1 Minute schrieb monolith:

Wie gesagt das ist die Folge der Anwendung eines Patterns (Link zur offiziellen Doku aber weiß nicht wie hilfreich der ist: https://laravel.com/docs/5.7/facades ) dass eine Klasse A nimmt und in eine Klasse B verpackt, wobei aber nur Methoden verpackt werden und keine Konstanten.

Ich glaube das Missverständnis zwischen @Whiz-zarD und dir liegt im Ursprung des Problems.

So wie ich es verstanden habe wurde die Klasse und deren Konstante vorher schon genutzt. Jetzt soll/muss aber dieses Pattern genutzt werden, was nur Methoden übernimmt, aber keine Properties. Soweit so gut.

Aber genau da liegt halt der Fehler, den @Whiz-zarD hier bemängelt: "Wieso war die Konstante überhaupt jemals public?"

Die Sichtbarkeit von Informationen sollte immer groß wie nötig und so klein wie möglich gehalten werden. Eine Eigenschaft (oder in diesem Fall genauer eine Konstante) die zu einer Klasse (oder einem Objekt) gehört, sollte nicht direkt lesbar sein, sondern eben nur über Methoden.

D.h. im Grunde ist die neu erstellte Methode doch nichts anders als der Getter für die Konstante, oder nicht? Und die sollte eigentlich idealerweise schon beim Erstellen der Klasse erstellt worden sein und alle Eigenschaften (Variablen und Konstanten) als private deklariert worden sein und nicht erst jetzt, wo ein Pattern genau das fordert.

[arlegermi]

vor 4 Minuten schrieb Rienne:

Eine Eigenschaft (oder in diesem Fall genauer eine Konstante) die zu einer Klasse (oder einem Objekt) gehört, sollte nicht direkt lesbar sein, sondern eben nur über Methoden.

Das ist doch Blödsinn. Wenn ich eine Konstante habe, die ich an anderen Stellen im Code brauche, dann muss ich da nicht extra eine Methode drumrum machen. So etwas wie Math.Pi oder Math.Tau muss man nicht hinter einem Math.GetPi() verstecken.

[Whiz-zarD]

vor 9 Minuten schrieb monolith:

Für was genau kannst du keinen Anwendungsfall konstruieren? Für das 1. Konstante-Methode-Ding oder für 2. Nutzung der Konstante außerhalb der Klasse?

Zu 1.

vor 12 Minuten schrieb monolith:

zu 1.: Wie gesagt das ist die Folge der Anwendung eines Patterns (Link zur offiziellen Doku aber weiß nicht wie hilfreich der ist: https://laravel.com/docs/5.7/facades ) dass eine Klasse A nimmt und in eine Klasse B verpackt, wobei aber nur Methoden verpackt werden und keine Konstanten. Wenn du mit Klasse B arbeitest klappt zwar B.machWas() aber nicht B.KONSTANTE_XYZ weil nur Methodenaufrufe auf A gemappt werden können.

Für das Facade Pattern ist das kein Hindernis. Das Facade Pattern abstrahiert lediglich mehrere Subsysteme zu einem simpleren System. Beispiel: Ich habe Klasse A und B und die fasse ich zu Klasse C zusammen. Natürlich kann dann die Klasse C auf die öffentlichen Methoden und Konstanten von A und B zugreifen, da C ja die öffentliche Schnittstelle von A und B kennt. Ich sehe also keinen Grund, wieso es üblich ist, im Facade Pattern die Konstante auch als Methode bereitzustellen. Wie gesagt, mag sein, dass da Laravel irgendeine verquirlte Art und Weise hat, wie es arbeitet aber das hat erst mal nichts mit dem Facade Pattern zu tun.

Wenn man dort sowieso eine Methode schreiben muss, frage ich mich, wieso dann noch großartig eine Konstante definiert werden muss. Lass sie doch weg und schreib den Wert in die Methode. Eine Methode, die nichts anderes tut, als eine Konstante zurückzugeben, ist redundant und führt dich jetzt zur Frage, wie man es testen soll. Anstatt:

class A {
    public const PI = 3.14;

    public function getPI() {
        return self::PI;
    }
}

einfach:

class A {
    public function getPI() {
        return 3.14;
    }
}

schreiben.

Es gibt da nämlich gar keinen Unterschied, da beim Kompilieren/Interpretieren der Aufruf von Konstanten in Literale umgewandelt werden. Der Aufruf self::PI wird später vom Interpreter eh in 3.14 umgewandelt und dann sieht die Funktion genauso aus, wie im unteren Beispiel. Wie man sieht, ist Konstante und Methode redundant.

 

[monolith]

Zitat

 

"Wieso war die Konstante überhaupt jemals public?"

Die Sichtbarkeit von Informationen sollte immer groß wie nötig und so klein wie möglich gehalten werden

 

Was genau stellt ihr in Frage? Ich denke nicht, dass ihr behaupten wollt, Konstanten dürften generell nicht nach außen sichtbar sein. Denn dann wäre es ein Designfehler einer Programmiersprache diese Sichtbarkeit überhaupt zu ermöglichen. Wäre mir neue, diese Ansicht.  

Zitat

Eine Eigenschaft (oder in diesem Fall genauer eine Konstante) die zu einer Klasse (oder einem Objekt) gehört, sollte nicht direkt lesbar sein, sondern eben nur über Methoden.

Von mir aus gerne, das wäre halt nur als Beispiel nicht so geeignet gewesen weil ich dann ja logischer Weise  beim Testen ohnehin nicht von außen auf die Konstante zugreifen könnte.

 

vor 28 Minuten schrieb Rienne:

D.h. im Grunde ist die neu erstellte Methode doch nichts anders als der Getter für die Konstante, oder nicht?

Ja.

vor 30 Minuten schrieb Rienne:

Und die sollte eigentlich idealerweise schon beim Erstellen der Klasse erstellt worden sein und alle Eigenschaften (Variablen und Konstanten) als private deklariert worden sein

Ja,... bis du dann die Konstante (die du erst nach Lesen des Codes entdeckt hast, weil sie ja anders nach außen gar nicht sichtbar war geschweige denn nach außen dokumentiert) zum Zugriff benötigst, die aber halt private ist, und du nicht direkt an sie herankommst, weil es halt mal keinen Getter gibt (weil man nun mal glaubte, die Konstante wäre für externe Belange nicht relevant*) und das aber dann Third-party-Code ist den du nicht verändern kannst. Der einzige Maintainer der Software bringt neue Releases aber leider nun noch alle paar Monate raus und in der Situation verfluchst du das information hiding.  

* = Ein Getter für eine Konstante ist ja ohnehin für gewöhnlich sinnlos - von Ausnahmen abgesehen. Getter sind Gegenstücke zu Settern. Setter gibt es aber bei Konstanten nicht, ergo sind Getter nicht sinnvoll.

[Whiz-zarD]

vor 19 Minuten schrieb monolith:

Was genau stellt ihr in Frage? Ich denke nicht, dass ihr behaupten wollt, Konstanten dürften generell nicht nach außen sichtbar sein.

Ich stelle die Sinnhaftigkeit eines Getters für eine Konstante in Frage, die du für das Facade Pattern für Sinnvoll erachtet hast.

vor 19 Minuten schrieb monolith:

* = Ein Getter für eine Konstante ist ja ohnehin für gewöhnlich sinnlos - von Ausnahmen abgesehen. Getter sind Gegenstücke zu Settern. Setter gibt es aber bei Konstanten nicht, ergo sind Getter nicht sinnvoll.

Aber genau das baust du hier: Einen Getter für eine Konstante.

[monolith]

vor 51 Minuten schrieb Whiz-zarD:

 Ich sehe also keinen Grund, wieso es üblich ist, im Facade Pattern die Konstante auch als Methode bereitzustellen.

Nein ist es nicht bzw. wird nicht gemacht da vermutlich technisch nicht auf dynamische Weise möglich.

 

vor 51 Minuten schrieb Whiz-zarD:

wie es arbeitet aber das hat erst mal nichts mit dem Facade Pattern zu tun

Sorry hätte erwähnen sollen dass es in der Vergangenheit eine große öffentliche Diskussion gab bezüglich ob das was Laravel macht überhaupt streng genommen eine Implementierung des Facade Patterns ist. Aber hey, das ist jetzt wirklich gaaanz weit im Offtopic.

Der Punkt ist, du hast das durch das Framework so vorgegeben.

vor 51 Minuten schrieb Whiz-zarD:

Wenn man dort sowieso eine Methode schreiben muss, frage ich mich, wieso dann noch großartig eine Konstante definiert werden muss. Lass sie doch weg und schreib den Wert in die Methode.

Theoretisch ja, dann müsstest du halt auch innerhalb der Klasse die Methode verwenden. Denke das ist jetzt Ansichtssache, ob es das nun besser macht oder man sagt, hey, ich spare mir wenigstens da wo es geht den Methodenaufruf. In deinem Beispiel müsste man (wenn man Facades nicht verwendet) zudem für externen Zugriff erst ein Objekt vom Typ der Klasse erzeugen.

 

vor 51 Minuten schrieb Whiz-zarD:

Eine Methode, die nichts anderes tut, als eine Konstante zurückzugeben, ist redundant

Für gewöhnlich ja, das will ich ja gar nicht bestreiten.  Aber (zum x-ten-Mal):

vor 51 Minuten schrieb Whiz-zarD:

führt dich jetzt zur Frage, wie man es testen soll.

Nein eben nicht. Das war nur ein Beispiel. Es geht um etwas anderes. Ggf. wäre folgendes verständlicher - birgt aber die Gefahr, neue Fragen aufzuwerfen: "Man hat nur eine Klasse mit einer Konstanten. Wie testet man die Konstante?"

 

Bearbeitet 10. Januar 2019 von monolith

[arlegermi]

Um mal von der Konstanten-Diskussion wegzukommen: In Unit-Tests werden die Ergebnisse vorgegeben wie sie zu sein haben. Da wird nichts von "woanders" her geholt. Das gilt für Konstanten, aber auch für alle Ergebnisse von Methoden.

Wenn du also eine Method Add(int a, int b) hast, dann testest du die mit 

Assert.AreEqual(4, Add(2, 2)) 

und nicht mit

Assert.AreEqual(2+2, Add(2,2))

(Jaja, trivial und so. Prinzip gilt auch für alle komplexeren Methoden.)

Genauso testest du eine Konstante auch mit

Assert.AreEqual(3, Konstanten.UnserSpeziellesPi)

Du kannst natürlich auch noch einen Test hinzufügen, der sicherstellt, dass der Wert, den du aus der Methode herausbekommst auch mit dem Wert der Konstanten direkt übereinstimmt.

[Whiz-zarD]

vor 12 Minuten schrieb monolith:

In deinem Beispiel müsste man (wenn man Facades nicht verwendet) zudem für externen Zugriff erst ein Objekt vom Typ der Klasse erzeugen.

Dann macht man eben eine statische Konstante draus. Wo ist das Problem?

vor 13 Minuten schrieb monolith:

Sorry hätte erwähnen sollen dass es in der Vergangenheit eine große öffentliche Diskussion gab bezüglich ob das was Laravel macht überhaupt streng genommen eine Implementierung des Facade Patterns ist. Aber hey, das ist jetzt wirklich gaaanz weit im Offtopic.

Sorry, dass meine Glaskugel kaputt war und ich nicht wusste, dass du im Eingangsbeitrag Laravel meinstest, als du das Facade Pattern erwähnt hast...  Ich kenne Laravel nun mal nicht und ist es nun zu viel verlangt, mal die Hintergründe zu erklären, wofür du das brauchst, weil ich den Sinn und Zweck deines Anliegens nicht verstanden habe und ich es deutlich gemacht habe, wieso ich es nicht verstehe.

vor 18 Minuten schrieb monolith:

oder man sagt, hey, ich spare mir wenigstens da wo es geht den Methodenaufruf.

oder: Hey! Ich baue mir mit Hilfe von Redundanz eine Mikrooptimierung ein und frage dann in einem Forum, wie ich das nun testen kann...

vor 22 Minuten schrieb monolith:

"Man hat nur eine Klasse mit einer Konstanten. Wie testet man die Konstante?"

Wozu testen? Was hat man davon, wenn man eine Konstante testet?

[monolith]

 

vor 17 Stunden schrieb Whiz-zarD:

ist es nun zu viel verlangt, mal die Hintergründe zu erklären, wofür du das brauchst, weil ich den Sinn und Zweck deines Anliegens nicht verstanden habe und ich es deutlich gemacht habe, wieso ich es nicht verstehe

Es war nun mal nicht mein Anliegen das zu diskutieren.

vor 17 Stunden schrieb Whiz-zarD:

ch baue mir mit Hilfe von Redundanz eine Mikrooptimierung ein und frage dann in einem Forum, wie ich das nun testen kann...

Wie gesagt, dass war ein Beispiel war das ich gewählt habe weil es klein ist. 

vor 17 Stunden schrieb Whiz-zarD:

Wozu testen? Was hat man davon, wenn man eine Konstante testet?

=>

vor 17 Stunden schrieb monolith:

Ggf. wäre folgendes verständlicher - birgt aber die Gefahr, neue Fragen aufzuwerfen

Ich glaube es führt zu keinen neuen Erkenntnissen das jetzt zu diskutieren, daher ist das Thema für mich jetzt abgeschlossen. Die Meinungen dazu sind ja soweit einstimmig. Allen Beteiligten Danke für die Antworten!

 

Bearbeitet 11. Januar 2019 von monolith