[feedhenry-dev] Mock libraries to use for unit test for Swift iOS SDK

[Corinne Krych]

On 10 March 2016 at 13:39, Timur Tatarshaov <ttatarsh at redhat.com> wrote:

> I assume preferable approach would be to decline usage of third-party
> libraries since Swift is fast evolving and quite perspective language, but
> I'm not that familiar with current SDK's complexity yet, to define where
> tooling of the language is enough and where third-party should be used. So
> I'll spend some time for to get familiar with SDK.
>
> 1. Nocilla(https://github.com/luisobo/Nocilla) is Objective-C oriented,
> no docs/examples for Swift. Supports ASIHTTP, it's powerful but probably
> too much for what's needed for our unit tests. We could use native or
> Alamofire(https://github.com/Alamofire/Alamofire)
>
> So here choice for OHHTTPStubs(https://github.com/AliSoftware/OHHTTPStubs)
> most likely. It's actively developing, supports Swift out of the box,
> documented and has MIT license.
>

+1
we used it in aerogear-ios-http too.


>
> 2. Cuckoo(https://github.com/SwiftKit/Cuckoo) for mocks generation. It
> feels that, complexity is too high for our needs and it doesn't fit
> language structure well. It adds extra entity in a build process, since
> uses command line tools to integrate for generation of mocks on the fly
> before actual build, which could add additional overhead for the automatic
> build process at the beginning.
> But it could help if amount of data to be mocked is high and we need some
> cross-integration of the data. Could be used in a process, if it would feel
> like amount of data to be mocked is going to be increased.
>

Yeap no real need atm
but we can revisit.


>
> 3. BDD style. I checked Kiwi(https://github.com/kiwi-bdd/Kiwi) and Cedar(
> https://github.com/pivotal/cedar) and we used this style for some uart
> tests, but it's a tests that run from outside and testing the existing box.
> I don't see it fits nicely into unit tests and Swift syntax.
>
> Quick/Nimble(https://github.com/Quick/Nimble)(Apache License Version 2.0)
> suits for the different than BDD style needs.
> It's positioned as a way "to express the expected outcomes of Swift" and
> inspired by Cedar, which is BDD style helper lib, in a sense of checking
> values only.
> It allows to evaluate result object easily and useful if objects are
> complex. I'm not aware about complexity of the output data of SDK's so far,
> but if it's needed library is welcome to be used.
> There are two approaches:
> - to start without it and integrate once complexity will increase
> - to use it right away if it's already required
> In a case of post-integration, it should go smoothly since it's just
> another way of evaluating expressions and doesn't interfere with the logic
> of the code.
> If we are at the beginning and not sure about complexity, I would
> recommend first way.
>

Good I started that way too


> Quick/Nimble is recommended.
>
> Opinions are very welcome.
>
> On Tue, Mar 8, 2016 at 8:45 AM, Timur Tatarshaov <timur at redhat.com> wrote:
>
>> As we develop unit tests for fh-ios-swift-sdk we need to evaluate which
>> mock libraries to use.
>>
>> 1. Mock http
>> For fh-ios-sdk (ObjC) we used to work with Nocilla to dynamic mock
>> (through swizzling) the HTTP layer.
>> For aerogear-ios-http (one of the lib we're going to use in
>>  fh-ios-swift-sdk), we mocked HTTP layer with OHHTTPStubs. Nocilla was
>> picked for FH sdk over OHHTTPStubs because it supports ASIHTTP lib, but
>> since we're now working with plain NSURLSession, we could unify the libs to
>> use.
>>
>> 2. dynamic Mock
>> in ObjC we used to work with OCMock (dynamic mock), in Swift, with the
>> static type aspect of the language, mocks are done by implementing
>> protocol, more "hand crafted". But still libraries like the one written by
>> Tadeas are worth investigating:
>> https://github.com/SwiftKit/Cuckoo
>>
>> 3. BDD style
>> Evaluate if BDD libs like Quick/Nimble could help writing test that read
>> nicely
>>
>
>
>
> --
> Timur Tatarshaov
> Quality Engineer, Red Hat Mobile
>
> mobile: +420 773 234 993
> bluejeans: https://bluejeans.com/ttatarsh/
> mail: *ttatarsh at redhat.com <ttatarsh at redhat.com>*
> Slack: Timur Tatarshaov(famers) <https://redhat.slack.com/team/famer>
> my calendar
> <https://www.google.com/calendar/embed?src=ttatarsh@redhat.com&ctz=America/New_York>
>
>
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20160310/367dda9c/attachment.htm>