Improve Test Coverage, and add Coveralls

[orta]

• @lazerwalker

We've improved the overal test coverage by adding tests for most of the public API. We're waiting on travis/coveralls to see the actual results, you would have to turn on coveralls yourself as we don't have admin rights to your repo.

https://coveralls.io/

We deleted your test project, and moved the tests on to the demo, you can check out our notes here: https://docs.google.com/document/d/1nyDmDxIH9tAUxA18NIfLw6V6HIYRH-4j2md6rZf2lEU/edit#

[orta]

Travis: https://travis-ci.org/orta/AMTagListView Coveralls: https://coveralls.io/r/orta/AMTagListView

All green

[coveralls]

Changes Unknown when pulling 1b0e62918734dbf0f4ef77ea907b857476f7f4b6 on orta:master into \ on andreamazz:master**.

[andreamazz]

Amazing job. Thank you!
Merged

[yas375]

I'm not 100% sure, but shouldn't set -o pipefail be set either in .travis.yml or in the test rake task?

From xcpretty's readme:

Important: If you're running xcpretty on a CI like Travis or Jenkins, you may want to exit with same status code as xcodebuild. CI systems usually use status codes to determine if the build has failed.

$ set -o pipefail && xcodebuild [flags] | xcpretty -c
#
# OR
#
$ xcodebuild [flags] | xcpretty -c && exit ${PIPESTATUS[0]}

[lazerwalker]

Good call – when Orta and I were working on that, none of our test Travis builds would have failed due to test failure (as opposed to, say, tooling setup failure).

Not sure if there's a good way to manually trigger that state (probably a good thing the tests aren't failing :P), but it's probably worth proactively fixing. I suppose there's no harm in throwing set -o pipefail into the vanilla rake test method, rather than needing to explicitly make a separate rake travis task.