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(a)gmail.com&gt;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/Ae... > [3] > https://github.com/cvasilak/aerogear-ios/blob/ohhttpstubs.helper/AeroGear... > [4] > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hi looks like #2 approach wins so I merged it. Thanks! On Jun 10, 2013, at 12:29 PM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: +1 for #2. Indeed second approach2 is more objective-c in the syntax. On 10 June 2013 10:15, Matthias Wessendorf <matzew(a)apache.org&gt; 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(a)gmail.com&gt;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/Ae... >> [3] >> https://github.com/cvasilak/aerogear-ios/blob/ohhttpstubs.helper/AeroGear... >> [4] >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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(a)apache.org&gt; 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(a)gmail.com&gt; wrote: Hi looks like #2 approach wins so I merged it. Thanks! On Jun 10, 2013, at 12:29 PM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: > +1 for #2. Indeed second approach2 is more objective-c in the syntax. > > > > On 10 June 2013 10:15, Matthias Wessendorf <matzew(a)apache.org&gt; 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(a)gmail.com&gt; 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/Ae... > [3] https://github.com/cvasilak/aerogear-ios/blob/ohhttpstubs.helper/AeroGear... > [4] > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev