AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Unit-Test für private/protected Member?

Ein Thema von mh166 · begonnen am 9. Sep 2014 · letzter Beitrag vom 10. Sep 2014
Antwort Antwort
Dejan Vu
(Gast)

n/a Beiträge
 
#1

AW: Unit-Test für private/protected Member?

  Alt 9. Sep 2014, 19:19
Wie ich die Klasse testen würde, muss ich ja keinem erzählen. Und das die Klasse so testbar ist, auch nicht. Der einfachste und den Code am wenigsten verändernde Weg wäre der, die private Methode zu testen. Alles andere würde Mocking bedeuten, oder Refactoring, oder beides. Wenn ich entsprechende Helfe habe: Super, die Load-Methode gemockt, um ein Element zu liefern, die Save-Methode deaktiviert und fertig.

Aber ohne Mocking?

Die Aussage war 'private Methoden müssen nicht getestet werden' und ich habe ein Beispiel gebracht, wo das doch sinnvoll wäre. Es ist ja nicht so, das man jeden Tag seine Klassen so schreiben kann, das man sie super testen kann. Meist ist es so, das man legacy Code hat, und nachträglich Tests erstellen muss, um das Kartenhaus zu stabilisieren. Und das man ausgelieferten Code nicht einfach mal so umschreibt, um ihn testbar zu machen, versteht sich ja von selbst. Modifizierer ändern geht gerade, aber selbst bei einem Refactoring würde ich 2x überlegen, ob ich das mache.

Also: Die Klasse *sieht* so aus und ich kann die Methode, die die Liste erstellt, nicht mocken. Weil ich nichts zum mocken habe, verdammt. Also, was bleibt? Die private Methode testen. Und wie teste ich die? Womit wir wieder beim Thema wären.

Und darüber kann sehr wohl getestet werden, ob deine Methode, die intern rumwurschtelt, richtig gearbeitet hat.
Mit Mocking: Ja. Sonst: Nein.
Die Methode lädt eine Liste -> Dateiname wird beim Test übergeben
Das ist kein Unit-Test, denn es werden Systemgrenzen überwunden. Fällt also weg. Außerdem kommen die Daten im Beispiel von einer Quelle, die man nicht simulieren kann. Blöd. Legacy eben.
modifiziert die Elemente nach Schema F -> interessiert hier nicht,
Na doch. Du schreibst den Test ja gerade, um die Einhaltung von 'Schema F' zu verifizieren und für die Zukunft zu garantieren.

Nur mal so: Wenn ich testbaren Code schreibe, würde ich eine TItemModifier-Klasse bauen, und diese separat testen. Aber wenn ich diesen Code, so wie er ist, testen müsste, würde ich den 'PrivateModifierOfItem' protected machen, eine Testklasse drumherum bauen und diese testen. Das ändert die Funktionalität garantiert nicht.

Testcode neben dem zu testenden Code ist blöd. Das sollte man nicht machen.
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.052 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#2

AW: Unit-Test für private/protected Member?

  Alt 9. Sep 2014, 20:50
Haaaalt, stop! Lasst uns bitte nicht vom Thema abdriften sondern uns nochmal vor Augen holen, was die Frage und Ausgangslage im ersten Post war (Markierungen von mir):
da ich zur Zeit versuche mir (möglichst) sauberen Code beizubringen, wollte ich gern auch Tests für mein Projekt schreiben. Sehr interessant ist dazu übrigens das Video von Nick Hodges Unit Testing in Delphi.

Soweit so gut. Habe also angefangen für meine Klasse einen Test (mit DUnitX) zu schreiben. Nun kam aber recht schnell ein Problem für mich auf: wie teste ich private Methoden? Oder wie prüfe ich den Inhalt von privaten Feldern?

Im Video sagte Nick "Only test the code that you want to work properly" — und naja, irgendwie will ich schon, dass auch private Methoden korrekt funktionieren.
Hier ist nicht die Frage nach Unittests in Legacy Code (da hätte man auch wohl direkt die entsprechende Lektüre empfohlen), sondern Clean Code und Unit Tests.
Und da steht meine Aussage: Clean Code bedeutet testbarer Code, testbarer Code bedeutet in Isolation testbarer Code, in Isolation testbarer Code bedeutet öffentliche API und nix anderes
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
8.277 Beiträge
 
Delphi 10.4 Sydney
 
#3

AW: Unit-Test für private/protected Member?

  Alt 9. Sep 2014, 21:32
Hallo,

also sorry, ich habe es nicht begriffen!
Wo ist denn nun das Problem?

Es gibt eine Klasse, die wird von einem Programm benutzt.
Das Programm muss also die Klasse mit Daten füttern.
Als Ergebnis liefert die Klasse irgendwas zurück.

Wo ist das Problem?

Die Testaufgabe muss doch heißen
"Funktioniert die Klasse?"


Heiko
Heiko
  Mit Zitat antworten Zitat
Benutzerbild von JasonDX
JasonDX
(CodeLib-Manager)

Registriert seit: 5. Aug 2004
Ort: München
1.062 Beiträge
 
#4

AW: Unit-Test für private/protected Member?

  Alt 10. Sep 2014, 06:43
Die Aussage war 'private Methoden müssen nicht getestet werden' und ich habe ein Beispiel gebracht, wo das doch sinnvoll wäre.
Die Aussage ist auch falsch - richtig wäre: private Methoden müssen nicht direkt, sondern sollten implizit getestet werden.

Ja, wer einen Haufen Mist als Legacy-Code hat, kann Clean-code-Paradigmen nicht immer folgen - da kann man dann auch nichts anderes machen als den Haufen durch Tests höher stapeln, und sich baldmöglichst um ein Refactoring kümmern.
Mike
Passion is no replacement for reason
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#5

AW: Unit-Test für private/protected Member?

  Alt 10. Sep 2014, 08:01
Korrekt. Man muss wirklich unterscheiden zwischen:
  • Legacy-Code 'as is', bei dem man mit möglichst wenig Trickserei akzeptable Tests bekommt.
  • Neuen Code, wo ich mit den entsprechenden Programmierparadigmen perfekte(*) Tests bekommen kann.

(*) Perfekt <> 100% Coverage !
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 10:17 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz