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

[Timur Tatarshaov]

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.

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.

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.
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20160310/55a8c8c8/attachment.htm>