Functional test with AndroidTestRule #84
Conversation
| androidTestCompile presentationTestDependencies.espresso | ||
| androidTestCompile presentationTestDependencies.testingSupportLib | ||
| androidTestCompile (presentationTestDependencies.espresso) { | ||
| exclude group: 'com.android.support', module: 'support-annotations' |
There was a problem hiding this comment.
Why do we need to exclude annotations here? Is this a transitive dependency?
There was a problem hiding this comment.
There is a conflict with dependencies, because of different versions of android support annotation. If I remove this line a I get this error :
Warning:Conflict with dependency 'com.android.support:support-annotations'. Resolved versions for app (21.0.3) and test app (23.0.1) differ.
|
@MehdiChouag you must also re-write mapper tests as currently they are using the old |
|
Closing due to inactivity. I'm planing to refactor the whole test suite. @MehdiChouag I really appreciate your efforts and contribution, I'm gonna reuse part of your code such as |
|
@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. |
|
@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 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 😃 |
|
👍 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 😃 |
Replace activities testing by AndroidJUnit4 and AndroidTestRule