-
Notifications
You must be signed in to change notification settings - Fork 7.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failure triggered by MockRetrofit's NetworkBehavior even though error level set to 0% #2355
Comments
Weird. Will look. |
Ok. So the problem is that you're calling The difference is subtle. Failures are IOExeptions that happen during the request. Errors are successful responses that do not have a 200 status code. By default errors already happen 0% of the time so your call basically does nothing. Failures, however, happen 3% of the time, and this is the value that you need to set to 0. |
Thanks for the clarifications! Whether the default behavior is good or not is a different discussion I guess... |
NetworkBehavior wasn't meant for use in unit tests but instead in runtime
"mock mode" to simulate real network behavior.
…On Mon, Jun 5, 2017 at 3:09 AM Alix ***@***.***> wrote:
Thanks for the clarifications! Whether the default behavior is good or not
is a different discussion I guess...
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#2355 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEEEdf1pPtapS6gBXltF6UCFwJHnk7aks5sA6m6gaJpZM4NuANc>
.
|
Because of the final classes in Retrofit, there is a need for built-in fakes unless going for bytecode manipulation frameworks such as PowerMock (rather not). For this reason we use MockRetrofit in our unit tests. |
I don't see the correlation. Your API services are just interfaces, after
all
…On Mon, Jun 5, 2017 at 9:47 AM Alix ***@***.***> wrote:
Because of the final classes in Retrofit, there is a need for built-in
fakes unless going for bytecode manipulation frameworks such as PowerMock
(rather not). For this reason we use MockRetrofit in our unit tests.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#2355 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEEEdR1AxIksiefJBJpbqHAq9jgo1Zqks5sBAbXgaJpZM4NuANc>
.
|
It's all about abstraction. I would like to keep Retrofits, Calls and Responses (and the API services) within one abstraction layer and to test that layer I have the choice to either mock the retrofits completely or to use fakes, such as MockRetrofit, which I think reduces some coupling at least. Since most classes in Retrofit are final I have embraced this approach. |
I have a test that uses the Mock Retrofit classes that fails (not always).
My setup (somewhat relevant dependencies):
testCompile 'junit:junit:4.12'
testCompile 'org.mockito:mockito-all:1.10.19'
testCompile 'org.robolectric:robolectric:3.3.2'
testCompile 'org.mockito:mockito-all:1.10.19'
testCompile 'com.squareup.retrofit2:retrofit-mock:2.3.0'
compile ('com.squareup.retrofit2:retrofit:2.3.0') {
// exclude Retrofit’s OkHttp peer-dependency module and define your own module import
exclude module: 'okhttp'
}
compile 'com.squareup.okhttp3:okhttp-urlconnection:3.8.0'
compile 'com.squareup.okhttp3:okhttp:3.8.0'
Code:
When it fails, I get this stacktrace:
The text was updated successfully, but these errors were encountered: