[aerogear-dev] iOS testing - HTTP mocking

[Matthias Wessendorf]

Did the check ->

*Executed 157 tests, with 0 failures (0 unexpected) in 14.247 (14.286)
seconds*

that is _ok_, so .... perhaps it's not that smart, to use proposal #2 ?


On Tue, Jun 11, 2013 at 8:56 AM, Matthias Wessendorf <matzew at apache.org>wrote:

> 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
>



-- 
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/97442f78/attachment.html