Die Haltung von Entwickler:innen für nützliche Testfälle

Tests sind in der modernen Softwareentwicklung ein unverzichtbarer Bestandteil, aber auch Testfälle sind letztlich Code, den Entwickler:innen schreiben, sodass je nach Situation Probleme auftreten können. Vorgestellt wird ein Beitrag, der sich aus objektorientierter Perspektive mit „nützlichen“ Testfällen befasst. (Koreanisch)

Der Kernpunkt ist, dass ein Test ein [Modul ist, das die Verantwortung trägt, ein anderes gekapseltes Modul zu testen]. Das bedeutet, dass auch Tests eindeutig Teil des entwickelten Codes sind und daher die Prinzipien der Objektorientierung einhalten sowie kontinuierlich verbessert und refaktoriert werden müssen. Daraus lässt sich nach dem SOLID-Prinzip auch ableiten, dass Testfälle weder auf konkrete interne Elemente des zu testenden Moduls (wie private-Methoden) zugreifen noch von ihnen abhängen sollten. Was ein Testfall überprüfen muss, ist ausschließlich die abstrakte Verantwortung des betreffenden Moduls; deshalb sollte getestet werden nur über die externe Schnittstelle des Moduls, die diese Verantwortung widerspiegelt.

Persönlich habe ich den Eindruck, dass dies einer der vielen Berge ist, die Programmieranfänger:innen überwinden müssen. Als ich Objektorientierung zum ersten Mal lernte, hörte ich in einer Vorlesung zwar, dass man private-Methoden nicht direkt testen sollte, und auch die Begründung dafür. Ehrlich gesagt habe ich das damals aber nicht wirklich verstanden. Ein gewisses Verständnis für den obigen Inhalt entwickelte sich bei mir erst lange Zeit danach.