I was trying to understand the design pattern used for TestRunner (package junit.textui) class of JUnit. The TestRunner class is extending a listener and has a reference of listener.
If it is the Observer design pattern, then why is it extending listener? it should have only reference of listener.
junit.textui.TestRunner
conforms to the Observer pattern, but it's the observer, not the subject. At least, it would be the observer—it isn't anymore.
JUnit exposes the TestListener interface: The TestResult class runs a TestCase, calling its own methods startTest
and endTest
. TestResult also contains a list of TestListener instances, and notifies all of them whenever a test is started or ended. This is the quintessential Observer pattern: TestResult is the subject, notifying its collection of TestListener instances, one of which could be TestRunner adding itself to the list.
That said, TestRunner doesn't currently add itself as a listener to TestResult, and has empty implementations of its required testStarted
, testEnded
, and testFailed
methods. Instead, it adds a ResultPrinter to the list of Listeners; I assume this was factored out of TestRunner at some point.
So, TestRunner is set up to be an Observer, but it no longer acts like one. All told, this actually demonstrates a strength of design patterns: It allows the opportunity to refactor the code and separate behavior by coding against those specific interfaces.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With