イカ?スマートフォン用の表示で見るやらなイカ?たぶん、iOS/Androidアプリの開発・テスト関係。Testing先週、クラウド名刺管理のSansan株式会社さんで開催された『最新事例から学ぶ!モバイル向けテスト手法勉強会』に参加させていただき、また「テストの種類とBDD」と題してお話してきました。Hasegawaどうしても前提となる話が増えてしまってテスト実装の話まで入れられませんでした。このプレゼンがつまらなくても、テストのことは嫌いにならないでください。後半は、BDDか、テクニック的な話(テストダブル、テストファースト、TDDとか)にするか迷ったのですが、今回の感触だとテクニックの話のほうがよかったかも知れません。20分ギリギリ話すつもり&電エースの話をしすぎた結果、BDDの部分は全部飛ばすはめになった今となってはどちらでもよかったですね。テストのテクニックに関しては、拙著『iOSアプリテスト自動化入門』の2.3、2.4に書いてありますので、そちらを参照頂けましたら幸いです。BDDのところで紹介しているテスト自動化ツールの連載は、昨日第6回が公開されました。聴講メモが混ざってしまっていたので、以下まとめて全体の話として書きます。テストを書いてるひとはまだ少ないUIのテストを過剰に自動化しようとする(そして挫折する)よりはいいと思います岸川さんの話にあったように、モデル(MVCのM)を中心に、ユニットテストは自動化していったほうがいいでしょうただし、「6〜7割実装してからテストを書きはじめる」のはテストを書いたことが無い人が真似しようとしても難しいです。テストしやすい実装になっていないと、テストを後から書くのは困難なので。ユニットテストのメリット、運用(岸川さん)変更を入れる際の安心感テストはgreenな状態を維持するカバレジはあまり気にしすぎない。CIは、スクリプトを書かずにできる範囲が広く、ほぼスクリプトレスで構築できる。Crashlytics"に乗り換えたTestFlightはiOS8以上なのがネックCrashlytics(クラッシュログ解析)を利用していたのでそのままiOS/Androidで同じサービスのほうが、テストする人はありがたい弊社はTestFlightがAndroidを切ったタイミングでDeployGateに移ったのですが、もう少し様子見。GitHubチャットでコントロールHubotに"release"を指示すると、リリースブランチを切り、PR、Travisでビルド、配布が流れるチャットにログが残るので、可視化、かつ、作業単位での分担・引き継ぎが容易Xcodeプロジェクトプロジェクトをcheckoutしたらすぐビルドできるように。プロジェクト固有ルールでの初期設定はなくす。CocoaPodsのようなデファクトを積極的に使うTarget、Configurationがたくさんあるとどれを使うべきかわからない。Schemeもたくさんあるとわからない。依存ライブラリのコードをプロジェクトに混ぜない。CocoaPodsを使えばlockファイルで差分もわかるなお、"混ぜない"は、プロジェクト内で修正を入れたりしないことが重要で、Podsから取得したコードをバージョン管理に含める運用の是非ではないです。過剰にUIのテストをしよう!みたいな雰囲気でなくて良かったビルド・配布から自動化に手を付けるというのは、良い傾向とは言え、あとからテストを書くのは困難なことが多いです。CIを導入しているなら、サイクロマティック複雑度を計測して酷いものからリファクタリングしていくアプローチもあり。アプリ開発はてなブログをはじめよう!nowsprintingさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。