Closed HelgeStenstrom closed 5 years ago
Okay because you are very good with reporting changes, can you make a new draft realease on relases section, so everytime we add something new, we update the draft release until we have a basic public release for the next version :)?
I don't know how to do releases. Is a draft release different from the existing releases, such as 9.0.4?
An existing unit test was changed a bit, to show how constructor chaining is useful. In the test, we replace the real Logger with a mocked Logger, with the same interface. The mocked logger doesn't do anything. In particular, it doesn't log, which is good i this unit test.
To make a draft release you follow the below steps :
Repository First Page => Releases
=> Draft a New Release
=> Complete a new tag up there for example 9.0.5 or 9.1.0 or 10.0.0 (for like major version release) i recommend 9.0.5 for now , also complete the description=> Then save as Draft
I did it for you you can check it on releases :) @HelgeStenstrom
What are the draft releases used for? Who will use them? And why is another site than GitHub involved?
In order to have some kind of review process, I don't think it's good if I merge my own pull request and create releases from them.
Back to the topic of this pull request? Do you think it's a good one? (I think so)
Yep it's a good one let me have a final look tommorow.
The draft release is created so we modify it until we publish it.
Through releases i am using jitpack.io which builds from the repository a jar that users can add to their projects as a Maven dependency.
Check for your own, stream-player 9.0.4 is a dependency on XR3Player and I haven't published it on MAVEN central, i am using JITPACK.IO
Two new constructors are provided. They allow the user to replace the default logger and executor services.
Constructor chaining is used. The parameterless constuctor now calls the logger constructor, which calls the construtor with executor arguments. In this way, by using and testing the parameterless constructor, we use and test all three constructors. (It's tested and it works).
A use case for the new constructors are: Unit testing without having to see a lot of logging messages) Unit testing where we spy on the executors, using a mocking framework, such as Mockito.
An advantage from an architecture point of view, is that depencencies become more visible. A future refactoring could be to remove the parameterless constructor. Then this class wouldn't be dependent on a logger implementation, but only on the Logger interface. Same with the executor services.