DefaultHttpClient execute returns null HttpResponse

2,333 views
Skip to first unread message

eveliotc

unread,
Dec 2, 2010, 7:30:07 PM12/2/10
to robolectric
Hi guys,

First all I'm falling in love with Robolectric is just pure awesome...
so far the best way TDD Android apps IMO

I've already done serveral successful tests, in most of them using
mocks with EasyMock in other stubs and fakes, and some of them using
Shadows... all of them work wonderful even the JSON integration tests
using the org.json library.

Second again me, with another problem, looking for help n_n

The problem now is with DefaultHttpClient, I'm doing an integration
test that as unit with mocks works awesome

But now I want to test with a real implementation so far resuming a
lot is something like the following dumb test:

@RunWith(RobolectricTestRunner.class)
public class HttpClientExecutorIntegrationTest {
@Test
public final void testDummyGet() {
HttpClient httpclient = new DefaultHttpClient();
HttpResponse response;
try {
response = httpclient.execute(new HttpGet("http://google.com/"));
assertNotNull(response);
assertTrue(response.getStatusLine().getStatusCode() == 200);
} catch (ClientProtocolException e) {
fail("ClientProtocolException");
e.printStackTrace();
} catch (IOException e) {
fail("IOException");
e.printStackTrace();
}
}
}

The problem is that as JUnit 4 test (obviously removing
@RunWith(RobolectricTestRunner.class)) works OK and I get green but as
Robolectric test doesn't work even linking the HttpClient jars and
dependencies just assertNotNull(response); always fails and
httpclient.execute(new HttpGet("http://google.com/")); always returns
null


Any ideas, suggestion or experience with this?

Thanks!

Tyler Schultz

unread,
Dec 3, 2010, 4:28:08 PM12/3/10
to robol...@googlegroups.com

Hi eveliotc,

Good to hear you're using and enjoying robolectric!

The first thing I'd check is to make sure the apache jars you're referencing are in 
the classpath ahead of the robolectric and android jars.  

Another approach may be to create two test classes.  One class that includes the @RunWith(RobolectricTestRunner) and one that doesn't.

--Tyler

Evelio Tarazona

unread,
Dec 4, 2010, 9:56:54 AM12/4/10
to robolectric
Hey Tyler,

Yup all jars are in classpath, and correct the solution is use that
approach of using @RunWith(RobolectricTestRunner) in some and in other
don't.

Thank you!


On Dec 3, 4:28 pm, Tyler Schultz <tylerschu...@gmail.com> wrote:
> Hi eveliotc,
>
> Good to hear you're using and enjoying robolectric!
>
> The first thing I'd check is to make sure the apache jars you're referencing
> are in
> the classpath ahead of the robolectric and android jars.
>
> Another approach may be to create two test classes.  One class that includes
> the @RunWith(RobolectricTestRunner) and one that doesn't.
>
> --Tyler
> *
> *
> *

Phil Goodwin

unread,
Dec 6, 2010, 2:11:44 PM12/6/10
to robol...@googlegroups.com
Hi Tyler,

Do you understand why he's getting null back from httpclient.execute()? It seems like he'd get a "Stub!" exception if he was calling a stripped jar, and we wouldn't intercept the call and return null if he wasn't. I don't immediately understand why using our test runner would be causing this problem for him.

Tyler Schultz

unread,
Dec 6, 2010, 2:22:43 PM12/6/10
to robol...@googlegroups.com
Thats a good point...?

Phil Goodwin

unread,
Dec 6, 2010, 6:40:42 PM12/6/10
to robol...@googlegroups.com
Hi Evelio,

We've just pushed a fix for this to the repo. We're now including versions of the httpclient jars that aren't stubbed out by the Android API and aren't shadowed either. This leaves Robolectric projects in the same position as other Java projects that use these libraries, which is that any HTTP requests that are made during testing will actually be sent, with possibly undesirable consequences. Of course, these problems can be mitigated in the usual ways, such as using mock objects or dependency injection to create barriers that prevent these requests from escaping from the test environment, but we are also considering whether it would be more desirable to create shadows for these classes instead. We would love to hear informed opinions about whether this approach would be useful.

Phil

Michael Portuesi

unread,
Dec 7, 2010, 1:27:58 PM12/7/10
to robolectric
Phil,

I personally would love to have shadow access to the HttpClient API.
I envision something along the lines of:

@Test
testWebServiceRequest() throws Exception {
ShadowHttpClient.setResponseCode( 200 );
ShadowHttpClient.addResponseHeader( "Content-Type", "application/
json" );
ShadowHttpClient.setResponseBody( jsonString );

myAppRESTGateway.doRequest( url );

assertThat( ....., .... );
}

This would be a nice way to test web service plumbing with an Android
app without having to rely on mocks, stubs, or external server
processes.

M.

Tyler Schultz

unread,
Dec 7, 2010, 1:54:28 PM12/7/10
to robol...@googlegroups.com
Great minds think alike, we're in the process of doing something very similar to that right now... we'll keep you posted.

--Phil & Tyler

Michael Portuesi

unread,
Dec 7, 2010, 2:11:55 PM12/7/10
to robolectric
I'm doing a happy dance right now....looking forward to seeing what
you come up with.

M.

On Dec 7, 10:54 am, Tyler Schultz <tylerschu...@gmail.com> wrote:
> Great minds think alike, we're in the process of doing something very
> similar to that right now... we'll keep you posted.
>
> --Phil & Tyler
>
Reply all
Reply to author
Forward
0 new messages