iOSオールスターズ2 https://eventdots.jp/event/602872
Create code coverage reports for iOS unit tests using new Xocde 7 code coverage feature. The Old Way I’ll start with back reference to another post I wrote earlier, which describes the process of getting code coverage reports using good old gcov. To try out the old approach checkout this repository and run the scripts. # Run tests with gcov instrumentation ./test-gcov.sh # Generate Cobertura cover
マッチャーフレームワーク for Objective-C/Cocoa ExpectaはGithubのメンバーが作ったマッチャーです。BDDフレームワークであるSpecta(これもGithub製)と組み合わせて使用すると、手軽にテストコードが書けます。特に非同期テストの書きやすさは秀逸です。是非皆さんも一度使ってみることをお勧めします。 このドキュメントは私がspecta/expectaから、自分が必要とする部分のみを抜粋して翻訳したものです。 翻訳に自信がない部分はそのままにしています。 セットアップ CocoaPodsを使用します。 target :MyApp do # your app dependencies end target :MyAppTests do pod 'Expecta', '~> 0.2.3' # expecta matchers # pod 'Specta', '
In this post, we explore the nature of Swift’s new error type, looking at the possibilities and restrictions for testing error handling implementations. We end with an illustrative example, and some helpful resources. How to Implement the ErrorType Protocol If we jump to the definition of the ErrorType protocol in the Swift standard library, we see that it doesn’t contain many obvious requirements
2014年のWWDCでは、"Testing In Xcode 6"という講演で XCTestの変更点について、以下の通り説明されています。 * 互換性の向上 * 非同期テスト用APIの追加 * パフォーマンス評価用APIの追加 この記事では、非同期テスト用APIの追加・パフォーマンス評価用APIの追加について説明します。 非同期テスト用APIの追加 XCode6のXCTestでは、非同期テスト用のAPIが追加されました。 バックグラウンドで実行するような処理やネットワークのI/Oなど、非同期な振る舞いをテストするときに使えます。 書き方 非同期な処理を実行するときに、期待する処理が完了したタイミングでXCTestExpectationのfulfillを呼び出すよう実装します。 そのときにテストケース側ではwaitForExpectationsWithTimeout:を呼び出して、期待する処
About the content This content has been published here with the express permission of the author. Software tests are great for verifying software behavior and improving the quality of your code. In this talk, we learn from Jeff Hui about tooling, techniques, and writing tested code with the Quick testing framework. He also talked about generative testing, a prevalent functional programming approac
ある程度の規模になっているObjective-CベースのiOSアプリで、「よっしゃSwift導入や!」ってなっても、 「開発者が馴染んでいない言語を実戦投入したら、コーディングガイドラインもないし、コード品質が下がってしまう」みたいな懸念があると、きっと思います。 でも、やっぱりSwiftは触ってみたいし、少しずつ触っておきたい、みたいなケースはないでしょうか? なら、簡単な導入として、単体テストだけSwiftで書いてみればいいんじゃない?と思ってやってみたらすごく簡単だったのでその紹介です。 前提 Obj-Cで書いているアプリ 単体テストは既にある. (フレームワークはXCTest) Swiftのテストケースを追加 おもむろに "New File..." から Test Case Classesを選んで、新しいテストクラスを追加します。 LanguageはSwiftにします。 ファイルを
Brian Gesiak さんをゲストに迎えて、Facebook, ComponentKit, React Native, Swift, Quick, Xcode などについて話しました。 Show Notes Facebook's iOS Infrastructure - @Scale 2014 F8 2015 - Facebook on iOS: Inside the "Big Blue App" ComponentKit | A React-inspired view framework for iOS ComponentKit | Why C++ React Native AsyncDisplayKit Nuclide - a unified IDE Thoughts on Atom modocache/Gift SwiftGit2/SwiftGit2 Swift APIs: Ge
Mar 20, 2015 Objective-Cではテストケース毎にオブジェクトの一部だけ挙動を変えたい場合に、OCMockなどのライブラリを使うのが普通でした。 それらのライブラリはNSInvocationやMethod Swizzlingなどを使ったいわゆる魔術的なコードで実現されていることが多く、 “テストコードを書いているのによくわからんコードが動いてる!”ってなってモヤモヤしたりします。 一方、Swiftではmanual mockingという手法が取られたりするみたいです。 例えば、 class Object { var foo: String { return "foo" } var bar: String { return "bar" } } class ObjectTests: XCTestCase { func testFoo() { class ObjectMock:
非同期処理のテストってどう書いてますか? 標準のXCTest自体がサポートしていれば良いのですがそうではないので、非同期処理のテストを書きたい場合には、その仕組みを自作するか出来合いのライブラリを利用する必要があります。現実的な選択肢としては、 GHUnitやKiwiなど非同期処理をサポートしたテストフレームワークを利用する GHunitの非同期処理のテストの仕組みを真似て抜粋したライブラリを利用する(意外とこれが多いかも?) expectaなどのマッチャーライブラリに付属の非同期処理の仕組みを使う となるかと思います。 ただ、私が調べた時点だとどれもしっくりきませんでした。 まず、GHUnitやKiwiなどを採択している場合には良いのですが、非同期処理のテストを書くという目的だけのためにそれらのフレームワークを使うというのは冗長すぎます。 また、GHUnitの非同期処理の仕組みだけを抜き
(Andy Myers and the CocoaPods Dev team. Creative Commons - Attribution-NonCommercial 4.0 International) iOSアプリを作るとき、今日ではCocoaPodsを用いて簡単に便利なライブラリの力を借りることができる。 ライブラリを利用するメリットは多い。自分でメンテナンスする必要がないので、放っておいても勝手に改善されていく。潜在的な問題があったとしても、多くの人が利用しているものなら誰かが気付いて直してくれる可能性も高い。また自分より優れたエンジニアの手によって、優れたインターフェースや実装になっているということも多い。何より、自分で実装する手間が省けるのがよい。 反面、デメリットについても考えなければならない。ライブラリがメンテナンスされなくなったとき、なにか問題が起こったり、あるいはAp
概要 スタートアップiOS勉強会 #3 http://www.zusaar.com/event/4557003 自分もこれで話す内容についてずっと考えていて、laisoさんのスタートアップの人材戦略とは何かを読むと先にLTの内容を公開していたのでこちらも公開することにした。 10分以下のLTだと細かいことは多分話せないので、先におおまかに公開し実際のLTでは自分の特に話したいことを集中して話すようになるのではないかと思う(もしくはジョブズが成仏した話みたいに当日思いつきでぜんぜん違うことを言うかもしれないし、もしくは近所にガールズバーができたから行ってみたらビール一杯3080円だった話になるかもしれない)。 スタートアップに関する話について 経験上、iOSアプリ開発ではWebアプリ開発のようにいきなり大人数で開発を進めることがないので、iOSアプリ開発での技術的ノウハウやあるあるネタはスタ
Swift is the best programming language you should learn and make your dream app easily. Swift programming is a powerful yet easy-to-learn coding language created by Apple. It's frequently used for developing iOS and macOS applications, as well as tvOS and watchOS apps. While you can use other languages to create Apple apps, Swift is the preferred language, and it's recommended because its code is
Objective-Cでクラスメソッドを置換するやり方について忘れがちなのでメモ テストコードを書いてるときなどに、テスト対象のコードの中で呼んでいるクラスメソッドをモックに差し替えたい場合があります。 本来であればその手の依存性はうまい事排除してあげるのが良いのですが、いかんともしがたい場合ですね。 Objective-Cはruntimeに触る事が出来るので割りとサクッとできます。 以下のクラスのメソッドを入れ替えてみましょう。
前回 はSenTestKitを用いてJenkins上で単体テストの自動実行を行いました。今回はGHUnitを使った単体テストの自動実行にチャレンジしてみたいと思います。またついでといっては何ですが、単体テスト時に必要になってくるモックを作成するためのライブラリOCMockも同時に導入してみようと思います。 ■なぜGHUnitを使うのか GHUnitを使うことで、SenTestingKitと比べて以下のようなメリットが得られます。 非同期処理のテストを行うための仕組みが用意されている(GHAsyncTestCase)これをSenTestingKitないし他のテスティングフレームワークでやろうとすると大変骨が折れます。 .app形式(要するに実際のiOSアプリケーション)でテストを実行するため、UIApplicationやUIWindowといったUIコンポーネントを使うクラスのテストが可能にな
また、テストを書く。 最近 iOS 界隈のテストのベストプラクティスについて調べているのですが、そこで目に留まった文章があるのでまずそれを紹介します。 How comfortable are you on a bike without a helmet? Writing code without tests is like riding a bike without a helmet. You might feel free and indestructible for now, but one day you’ll fall and it’s going to hurt. http://paulsolt.com/2010/11/iphone-unit-testing-explained-part-1/ ヘルメットを付けずに自転車を漕ぐのはとても快適ですね。でも、ふとしたある日に取り返しの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く