[aerogear-dev] iOS testing - HTTP mocking

Matthias Wessendorf matzew at apache.org
Tue Jun 11 02:56:12 EDT 2013


Looking at the branch:

One thing that I noticed is the extreme larger amount of, for passing the
tests.

Branch_of_PR:
Executed 156 tests, with 0 failures (0 unexpected) in 52.261 (52.285)
seconds

Master_branch (aerogear/aerogear-ios):
Executed 157 tests, with 0 failures (0 unexpected) in 12.194 (12.217)
seconds





Now I am wondering, that that OHHTTPStub is really _that_ slow...
Do you have an numbers from the proposal #1 ?

-Matthias




On Tue, Jun 11, 2013 at 8:50 AM, Christos Vasilakis <cvasilak at gmail.com>wrote:

> Hi
>
> looks like #2 approach wins so I merged it.
>
> Thanks!
>
> On Jun 10, 2013, at 12:29 PM, Corinne Krych <corinnekrych at gmail.com>
> wrote:
>
> +1 for #2. Indeed second approach2 is more objective-c in the syntax.
>
>
>
> On 10 June 2013 10:15, Matthias Wessendorf <matzew at apache.org> wrote:
>
>> Hi,
>>
>> I think I do prefer the approach #2 (the "mock helper" class)
>>
>> -M
>>
>>
>> On Fri, Jun 7, 2013 at 10:32 AM, Christos Vasilakis <cvasilak at gmail.com>wrote:
>>
>>>  Hi team,
>>>
>>> for further improvements of our unit tests we have switched the http
>>> mocking mechanism we use (our own NSURLProtocol impl)  to the popular
>>> OHHTTPStubs[1] project,  a library currently recommended by the
>>> AFNetworking networking lib we use.
>>>
>>> The basic mechanism is straightforward to use and encapsulated in one
>>> method:
>>>
>>> return [OHHTTPStubsResponse responseWithData:data
>>>
>>>                                   statusCode:status
>>>
>>>                                 responseTime:responseTime
>>>                                      headers:headers];
>>>
>>>
>>> in which a stubbed response is returned to the client.
>>>
>>> Now, based on this mechanism,  we have abstracted a bit and created
>>> methods such as:
>>>
>>>  + (void)mockResponse:(NSData*)data;
>>>
>>>  + (void)mockResponseStatus:(int)status;
>>>
>>>  + (void)mockResponseTimeout:(NSData*)data status:(int)status responseTime:(NSTimeInterval)responseTime;
>>>
>>>
>>> This gives the advantages that a) clearly indicate what http scenario we
>>> are testing  and b) remove params that don't make sense for the particular
>>> scenario under testing e.g. that is we simulate a status of  (404) but we
>>> need to pass all params eg. data, interval, timeout, etc.  But this doesn't
>>> limit us, we can do that if we want and use the full blown method with all
>>> the params attached.
>>>
>>> I have created two branches in my fork, one that uses a blocks approach
>>> inside the testing class [2] and one that the functionality is extracted in
>>> a helper class that the testing classes can use [3].  The second approach
>>> was created because there was common code and didn't want to duplicate it
>>> over the testing classes.
>>>
>>> I would be interesting to know what is your comments on it?
>>>
>>> Thanks,
>>> Christos
>>>
>>>
>>> [1] https://github.com/AliSoftware/OHHTTPStubs
>>> [2]
>>> https://github.com/cvasilak/aerogear-ios/blob/ohhttpstubs/AeroGear-iOS/AeroGear-iOSTests/AGRestAdapterTests.m#L33-L51
>>> [3]
>>> https://github.com/cvasilak/aerogear-ios/blob/ohhttpstubs.helper/AeroGear-iOS/AeroGear-iOSTests/utils/AGHTTPMockHelper.m
>>> [4]
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130611/69833ef7/attachment-0001.html 


More information about the aerogear-dev mailing list