@MehdiChouag you must also re-write mapper tests as currently they are using the old AndroidTestCase and with junit4 and AndroidJUnitRunner they won't work. In general seems OK 👍

Closing due to inactivity. I'm planing to refactor the whole test suite.
@spirosoik thanks for reviewing it. 👏

@MehdiChouag I really appreciate your efforts and contribution, I'm gonna reuse part of your code such as AndroidTestRule. 👏 😄

@android10 yes must be completely different. We must split down the unit tests and the instrumentation tests in presentation layer according to junit4 and AndroidJUnitRunner .

@spirosoik right. My next step is to refactor the project, so only one module exist. I need to re organize projects as well :). As usual, any ideas are welcome.

@android10 do you mean one module for every layer?

@spirosoik it is not necessary to have 3 different modules for each layer as the current project has.
It is a work in progress and before merging I will create a discussion in order to get feedback.
Here it is: #103

@android10 why did you decide this, just I am wondering your thoughts :) ? My opinion, it's great the multiple module approach as it's easier the code navigation and minimises the scope in different independent modules.

@spirosoik of course there is no final decision here, that is why I opened a PR, 😃 and I want most people to agree before moving parts on master 🔥

From my perspective, having everything in a single module favors classes scopes and package organization (the current approach obligate us to have many public classes that should not be public).

Also I don't see this organization into modules scaling so well since there is no package organization by feature, that is why I would like to get input on this.

@android10 the only problem with current implementation as you said is the API by the software's design perspective. If we go through Effective java for sure some rules are not applied here but I think these can be used in this case also. During our implementation we changed the visibility for a few things and we used eg. package-level especially in data module. We also have a core module with some stuff like Presenter, UIThread etc.

BTW based on your approach we are packaging by feature and it scales nicely until now and we have a lot of code.

But it's a good time to discuss your new approach :)

@spirosoik glad to hear that. Let's keep it up in another discussion. Once I'm done with the PR, I will open one to get input and see whether or not it worth a try 😃
Thanks again buddy!

👍 I am fan of your great work. @android10 BTW are you open for a presentation here in Greece?

@spirosoik Thank you! About a presentation, of course! Would love to and meet you guys in person! 😃

@android10 Great I will inform you soon for the details 😃