Sollte dies bedeuten, dass private und geschützte Methoden nicht testwürdig sind?

Nein, das soll bedeuten, dass testwürdige Methoden wahrscheinlich öffentlich sein sollten - möglicherweise in einer anderen (neuen) Klasse.

Sollte man über WhiteBoxTests die Nase rümpfen? --gR

Wenn Du unter WhiteBoxTests das Testen von nicht-öffentlichen Innereien meinst, denke ich schon.

In dem Schreiben von Tests aufgrund von Wissen über nicht-öffentliche Teile einer Klasse (z.B. Randbedingungen oder Spezialfälle, die nicht über das öffentliche Interface ersichtlich sind) sehe ich kein Problem.

Meiner Meinung nach sollten wir zwischen der Testbarkeit und der Sichtbarkeit bzw. dem Zugriffschutz unterscheiden, denn es sind zwei unabhängige Angelegenheiten.

Naja, nicht vollkommen unabhängig - weniger sichtbare Dinge sind auch umständlicher zu testen, so scheint es mir.

Könnten wir orthogonal sagen?

Als Konzepte, ja. Ich verstehe aber offensichtlich nicht ganz, was diese Orthogonalität für Auswirkungen auf diese Seite haben sollte. Was schlägst Du vor?

Sicher, die Tests entlang einer öffentlichen Schnittstelle können wertvoller sein als Tests innerhalb eines "Moduls", aber UnitTests (im Gegensatz zu AkzeptanzTests) sollten auch innerhalb eines "Moduls" ihren Platz haben. UnitTests sollten doch Funtionalität testen, die die Entwickler als eine sinnvolle Einheit wahrnehmen. Solche Einheit muss nicht unbedingt mit einem "Modul" identisch sein. (Ich spreche bewußt von "Modulen" und nicht von Klassen, denn, wenn wir von öffentlichen Schnittstellen sprechen, sollten wir uns nicht auf Klassen beschränken.)

Ich gebe Dir Recht, dass man eine sinnvolle Einheit der Funktionalität wohl in einer oder mehreren Klassen unterbringen sollte und die Funktionalität als die Schnittstelle (oder deren Teil) dieser Klasse(n) veröffenlichen sollte. Allerdings müssen diese Klassen selbst nicht "veröffenlicht" werden, und selbst eine "Innerei" einer größeren Einheit sein. (Sei es in Java eine package private oder private innere Klasse, in C++ eine private innere Klasse, oder eine Klasse, die nicht in einer Headerdatei veröffenlicht wird)

Mir scheint das Problem hier im wesentlichen zu sein, dass die zwei Konzepte "öffentliche Schnittstelle" (was legt das Modul anderen Modulen offen) und "veröffentlichte Schnittstelle" (was legt das Entwicklungsteam anderen Entwicklern offen) vermischt sind. Siehe dazu auch Public versus Published Interfaces (PDF) von MartinFowler.

Ich habe die öffentliche Schnittstelle (in Sinne public) gemeint, denn die Testbarkeit wird dadurch, dass eine Schnittstelle nicht published ist, nicht behindert. (Übrigens, zu der veröffentlichten Schnittstellen im Sinne published können auch protected Methoden und Klassen gehören.) Die Fowlersche Unterscheidung zwischen public und published spielt eher eine Rolle, wenn wir uns über UnitTests vs AkzeptanzTests unterhalten.

OK, dann bleibe ich bei meiner Behauptung, dass es eine konstruktive Annahme ist, für jede testwürdige Methode würde es eine Stelle geben, an der sie sinnvoller Weise auch öffentlich ist. Kannst Du ein Gegenbeispiel geben?

Ich glaube nicht, dass da unsere Meinungen weit außeinander liegen. Es geht nur darum, wie "groß" ist der Bereich, in dem die Methode sichtbar ist. Ein Beispiel wären möchlicherweise folgende Strukturen:

public class Foo { private static class Bar() { void testwürdigeMethode() { ... // Diese Methode ist nur von Foo sichtbar } } }

oder

package mypackage; class Foo { public void bar() { // Klasse Foo ist nur in mypackage sichtbar } }

Yep, genau darum geht es! :)

Zeige mir ein konkretes Beispiel, bei dem es nicht sinnvoll möglich ist, den Code so umzustrukturieren, dass die testwürdige Klasse/Methode als public deklariert werden kann. Ich wage die Behauptung aufzustellen, dass das Überlegen, wie das doch möglich ist, uns dann höchstwahrscheinlich zu einem besser entkoppelten Design führen wird.

In jedem solchen Fall steht man dann vor der Frage, wie die Tests an die Funktionalität, die normalerweise nicht öffentlich ist, zugreifen können. Eine Lösung ist, die Tests in dem Bereich, aus dem die Funktionalität sichtbar ist, zu implementieren. Die Folgefrage ist dann, wie man die Auslieferung der Tests verhindert. (Mann will ja nicht BloatWare? prodzuieren, die Tests sind ein Teil der Entwicklung, nicht ein Teil der Anwendung selbst) -- gR

Andererseits kann es unter Umständen auch ganz praktisch sein, die Tests beim Kunden laufen lassen zu können, um Konfigurationsproblemen auf die Spur zu kommen. -- IljaPreuß

• TestenVonNichtÖffentlichenMethoden
• WardsWiki:MethodsShouldBePublic