search

sockeqwe / mosby

A Model-View-Presenter / Model-View-Intent library for modern Android apps
http://hannesdorfmann.com/mosby/
Apache License 2.0
5.49k stars 841 forks source link

MVI mocked presenter blocks main thread on espresso tests #249

Closed emanzanoaxa closed 7 years ago

emanzanoaxa commented 7 years ago

I'm trying to write some UI tests with espresso. But when I mock the presenter with mockito (the createPresenter() method of the fragment/activity returns a mock), the main thread is never idle and the tests keeps waiting until the espresso timeout is reached. My goal is to call the "render()" method with mocked view states and check if the view is displaying correctly, that's why I'm mocking the presenter, because I don't need it and I want to isolate the view for the tests. When I create a "real" presenter with mocked dependencies on the constructor instead a mocked one, the main thread is not blocked and the test runs fine. I've been searching what can be blocking the main thread but I don't see what can it be.

Somebody know what can be blocking the main thread? Or If I need to mock something else on the presenter with mockito in order to keep the main thread dle?

MVI 3.0.04

sockeqwe commented 7 years ago

Not sure if I understood you correctly (nor which idling issue you face) but if you just want to check if ViewState is "rendered" correctly you can directly call MyActivity.render(myState) and then make assertions via espresso. No Presenter needed at all to test "rendering"

Emilio Manzano Marcos notifications@github.com schrieb am Do., 1. Juni 2017, 12:28:

I'm trying to write some UI tests with espresso. But when I mock the presenter with mockito (the createPresenter() method of the fragment/activity returns a mock), the main thread is never idle and the tests keeps waiting until the espresso timeout is reached. My goal is to call the "render()" method with mocked view states and check if the view is displaying correctly, that's why I'm mocking the presenter, because I don't need it and I want to isolate the view for the tests. When I create a "real" presenter with mocked dependencies on the constructor instead a mocked one, the main thread is not blocked and the test runs fine. I've been searching what can be blocking the main thread but I don't see what can it be.

Somebody know what can be blocking the main thread? Or If I need to mock something else on the presenter with mockito in order to keep the main thread dle?

MVI 3.0.04

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sockeqwe/mosby/issues/249, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjnrhpJJlpoYlb2p1daVnHXyVSm72YAks5r_pJQgaJpZM4NsydV .

emanzanoaxa commented 7 years ago

Thats correct, but I cannot return a null presenter on the createPresenter() method because MVI lib needs it. That's why I need to return a no-op mocked presenter, but If I do that the main thread gets blocked by something related to mosbys base MVI classes.

sockeqwe commented 7 years ago

Oh, that shouldn't be blocking. Maybe that's a bug internally, although I can't think right now why or where a blocking interaction with Mosby components like presenter takes place. Is your app open source so that I could debug that specific use case?

Emilio Manzano Marcos notifications@github.com schrieb am Do., 1. Juni 2017, 13:36:

Thats correct, but I cannot return a null presenter on the createPresenter() method because MVI lib needs it. That's why I need to return a no-op mocked presenter, but If I do that the main thread gets blocked by something related to mosbys base MVI classes.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/sockeqwe/mosby/issues/249#issuecomment-305468111, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjnrhtpMcmD9owPJunNAYcwse3rIX9rks5r_qJXgaJpZM4NsydV .

emanzanoaxa commented 7 years ago

Unfortunately is not open source, I'll continue looking to see if I find the problem. I'll post here if I find something, thanks for your reply (and for this great lib) :)

sockeqwe commented 7 years ago

I will try to reproduce it, but I can't say when because I'm more busy as I wanted to be right now.

Silly question, but do you increase the idling counter somewhere? Would it be decreased in Presenter somehow which in your case would never be reached so it will cause Espresso to wait until time out because counter is never 0?

If not, you could do the following: First, set a breakpoint of log in your onResume(). If that one ever reaches then it is definitely not Mosby who is blocking. Do the same for your view.render() method to verify whether or not this method has ever been called.

If you never reach the break points / logs of onResume() and view.render() then try the following.

set a break point in your Activity / Fragment onCreate() and onStart() method. Then step into the super call until you reach a class name "Mvi*Delegate" something. Then debug this one internally step by step to determine if there is a blocking call. If you find one, please report it.

emanzanoaxa commented 7 years ago

Sorry It was not a mosby related issue, with some emulators/devices the UI get blocked (I suppose because some other dependency of the app was blocking the UI on the emulators). I was trying with a new test app and the MVI lib and all was working fine. So this can be closed.

Thanks anyway :)

sockeqwe commented 7 years ago

Thanks for your feedback!