非同期のテストができないのでGHUnitを使っていたのですが、やっぱりCmd+U一発で単体テストが走る便利さがいいなーと思い、ためしにSenTestingKitで非同期のテストができないかやってみたらできちゃったので公開します。
https://github.com/akisute/SenAsyncTestCase
ライセンスはMITライセンスとします。
使い方とか例とかはREADMEを見たりテストケースを見てみたりしていただければ一発でわかるかと思います。あ、もちろんSenTestingKit.frameworkが必要ですよ。
2012年3月17日土曜日
2012年3月4日日曜日
Unity 3.5でバージョン管理をする
およそコンピュータを使った仕事に該当するものでしたら何でも、複数の人物が同時に作業するための何らかの仕組みが必要になるのは、コンピュータを使った仕事に関わっている人でしたら皆ご存知かと思います。特に開発業務といえばgitやhgといったバージョン管理システムの出番になります。そういうわけで今回は Unity プロジェクトでのバージョン管理について一ヶ月間ほどやってみた結果をご紹介したいと思います。
■Unity 3.4以前の場合
そんな暗黒時代のことは忘れましょう。
■Unity 3.5以降の場合
Unity 3.5から新しい仕組みが導入され、 Unity Asset Server というビルトインの
http://unity3d.com/support/documentation/Manual/ExternalVersionControlSystemSupport.html
これによると、以下の手順を踏むのが良いようです。
- メニューの Edit -> Project Settings -> Editor から、 Version Control の Mode という項目を探し、 Metafiles を選択する。これで外部のバージョン管理システムが導入できるようになります。このチェックを入れると、
- Libraryディレクトリが重要なメタデータを管理するディレクトリではなくただのキャッシュディレクトリになり、バージョン管理をしなくてよくなる。
- 新たにAssetsディレクトリ以下のすべてのファイルとディレクトリについて.metaファイルが生成される。
- 新たにProjectSettingsディレクトリが生成される。
- メニューの Edit -> Project Settings -> Editor から、 Asset Serialization の Mode という項目を探し、 Force Text を選択する。この手順はどちらかと言うとおまけです。これを実行すると、ほとんどのAssetファイルがバイナリではなくテキスト形式で保存されるようになり、diffやmergeが行えるだけではなく差分だけをコミットするようになるためバージョン管理システムが扱うデータ量が減ります。
- プロジェクト配下のAssetsディレクトリとProjectSettingsディレクトリをバージョン管理システム配下に追加する。それ以外のファイルは追加しなくて良い。
・・・ところがぎっちょん、実際にやってみると出るわ出るわ問題の山。
■.metaファイルがどこからともなく勝手に生成される
これが最大の問題です。外部バージョン管理をするためにUnityが.metaという名前のメタファイルをテキスト形式で生成するのですが、コイツがトラブルを起こしまくります。
- ファイル削除時に.metaを消すのを忘れて、同じ名前のファイルをあとから作成しようとして.metaがぶつかりトラブルになる
- ファイルも.metaもバージョン管理下から確かに消したはずなのに、なぜか.metaファイルだけが勝手に復活している
- ブランチを移動すると急に.metaファイルが湧いてきて、ブランチのマージ時に衝突する
- gitの場合
- gitはディレクトリをバージョン管理対象に含めないため厄介なことになります。通常はgit pull時にmerge/rebaseが実行され、その際に空になったディレクトリは削除されるのですが、merge/rebaseの最中に衝突が発生したりすると問題が大きくなります。merge中に裏でUnityが動いていると空ディレクトリの.metaがその場で生成されて、考えるだけでも恐ろしいことになったりします。 通常はこれで問題ないのですが、merge/rebase時に衝突が発生していて、裏でUnityが動いていたりすると酷いことになるみたいです。
- hgの場合
- hgはgitと同様にディレクトリがバージョン管理対象外なのですが、hg update時に空になったディレクトリをきちんと削除してくれます。これはupdateがworking directoryの中身を指定されたリビジョンの状態にするから、という認識です。gitと違いpullやupdate時にmerge/rebaseを実行しないためトラブルになりづらいのか？などと考えてますが実際に苦労したわけではないのでよくわかりません。おそらくgitよりはトラブルになりづらいとは思います。 1および3にupdateすると、きちんとFolderやOtherFolderが削除されてくれます。いい感じ。
- svnの場合
- ディレクトリもバージョン管理の対象にするので問題ありません。以下の図を参照。 r2のような削除の仕方をするとFolderが残ってしまうためFolder.metaが生成されてしまうのですが、普通はディレクトリを消したときはr4のような削除の仕方になるので問題がないはずです。
元ファイルを移動したり削除した際に.metaを消さなくてはいけないというだけでも極めて面倒で、相当なトラブルになりました。そもそもがUnityを使っているプロジェクトのメンバーが全員バージョン管理システムに慣れていないため、とりあえずバージョン管理システムのGUIツールがいうがままに変更を全部コミットするだけという具合の運用に。.metaだけが延々と残って衝突が繰り返されるという悲惨な状況が発生してしまうこととなりました。これはUnityのせいではなくメンバーがバージョン管理の考え方を正しく理解していないのが問題なのでツールは何を使っても発生しうるのですが、.metaがなければここまで問題は拡大しなかったと思います。
いっそignoreしてしまいたいぐらいなのですが、この.metaにファイルごとのメタ情報が全て詰まっているため、当然ignoreするとプロジェクトがブッ壊れます。これはひどい＞＜
本家のドキュメントで例にされているのがgitでもなくhgでもなくsvnであるあたりを見ると、なんだかsvnで動作させることしか考えてなさそうな印象です・・・
■.unityファイルがマージできない
.unityファイル自体はテキスト形式にできるのですが、中で使われているAssetのIDがちょっと触れただけでものすごい勢いで変化したり、他人の環境では別の値になったりするため、殆どの場合マージできません。iOSプロジェクトのxcodeprojファイルみたいな感じです。こればかりはマージを諦めるしかありません。
■まとめ
最初はgitを使って管理をしていたのですが、上記に挙げたような問題が多発しまくって回らなくなってしまいました。別のバージョン管理システムを使うことも検討したのですが、そもそもメンバーのバージョン管理に対する知識が足りていない上に.metaが存在する以上hgやsvnに変えても問題が根本的に解決しそうにないと判断し、結局社長に頼んでAsset Serverを購入して試してみることになりました。がっかしです＞＜ ですがAsset Serverならば.metaを使わないでバージョン管理できるので問題を根本的に解決できそうです。
逆に言えば.metaに気をつければそれ以外の箇所ではgitでもあまり問題になりませんでした。バイナリを大量に扱うため重いのではないかと懸念されていましたが、github経由ででも問題なくpush/pull出来る程度の重さにしかならなかったです。ということで.metaとうまく付き合えるチームメンバーが揃っているのであれば、Asset Serverなしでも十分やっていけるのではないかと思いました。
個人的にUnityでバージョン管理をする際におすすめする外部バージョン管理システムはsvn、可能であればPerforceです。git/hgのようにブランチを主体とするバージョン管理システムはブランチを切り替えた瞬間に.metaに殺されるケースが多々あるため、ブランチの使用そのものが非推奨となり、力が発揮できません。mergeについてもバイナリファイルやmergeできないテキスト形式のファイルが多くて結局意味がない気がします。どうしても分散VCSを使いたい！というならhgをお勧めします。ブランチ切り替えは常にupdate -Cすることで対応できるかなと。bazaarはわからないのでノーコメント。gitはpull時の衝突の最中に裏でUnityが動いていて大爆発するケースがあったのでやめておいたほうが良いです。hgなら少なくともpull/update時に爆発することはないはずですからね。
次はAsset Serverを試してみて、使用感を書いてみようかと思います。果たしてお値段に見合った効果は得られるのか！？乞うご期待です！
スタイラスペンの先端を保護する画期的な方法を思いついた
iPadなどのタブレット端末向けにスタイラスペンを持ち歩いていると、先端が破損してしまったり書き味が悪くなってしまったということはありませんか？最近のスタイラスペンの先端は繊細なシリコンゴムでできているものが主流で、持ち運びの最中に強い力がかかったりしてしまうと書き味が悪くなってしまうのです。そこで今回ご紹介したいのが、 Bamboo Stylusにマジックラッションペン No.300のキャップがジャストフィットする ってことなんです。こうやって写真のようにラッションペンのキャップをBamboo Stylusにつけてしまえば、持ち運んでいる最中にペン先が痛むことがありません！
Bamboo Stylusはクリップが取り外せるので、書いている最中はこんなふうに後ろにキャップが付けられます。
これで随分とペン先の劣化に悩まされることがなくなりました。これから発売される高級スタイラスは先端保護のためにキャップを付けて欲しいなぁと思った次第です。
■以下完全に余談: こんなことを思いついた経緯
もともと私は以前からiPad向けのスタイラスマニアで、よさそうな新製品が出るたびに買っては買っては試し、気に入ったものはポケットに入れて常に持ち歩くようにしています。
参考: http://akisute.com/search?q=スタイラス
その中でも特に書き味が素晴らしく、気に入っているのがBamboo StylusとSu-Penです。
 | Wacom iPad/IPad2/iPhone4対応 描画、ポインティングに最適なタッチペン Bamboo Stylus CS-100/K0 ワコム 2011-05-27 by G-Tools |
 | iPad/iPhone用スタイラスペン Su-Pen P101M-AS 7knowledge by G-Tools |
しかしながらこの２本はどうも先端の耐久性が他の製品にくらべて今ひとつなのか、ポケットに入れて持ち歩いているとどんどんペン先が劣化してしまうのです。まず最初にSu-Penが一月程で書けなくなってしまいました。TwitterでぼやいていたらSu-Penの担当の方に迅速かつ丁寧な対応をいただき、初期不良交換までしていただいたのですが、新しいペン先もやっぱり一月でダメになってしまいました。ものすごく丁寧な対応をしていただいたのになんかすみません＞＜ Bamboo Stylusも三ヶ月ほどでペン先が死んでしまうため、こちらは購入後ペン先を２回も交換しています。これは悲しい。
そんな具合でスタイラスのペン先の劣化に悩まされていたある日、会社に落ちていた鉛筆と鉛筆キャップを見てふと思いついたのです。 そうだキャップを被せれば良いじゃん と。よくよく考えたら市販のペンは全てペン先にキャップが付いているかノック式になっていてペン先が収納できるようになっているんですよね。どうしてスタイラスにペンキャップがないのかと。早速東急ハンズの文房具コーナーにダッシュしてそこら中のペンのキャップを引剥して Bamboo Stylusに付けてみました。その結果たったひとつだけBamboo Stylusにジャストフィットするペンキャップが見つかったのです。それがマジックラッションペン No.300！
 | 寺西化学工業 マジックラッションペン Ｎｏ．３００ 黒 寺西化学工業 by G-Tools |
まさかこんな所で1960年代から続くロングセラー製品と最先端技術が融合するとは！
2012年2月9日木曜日
ゲーム作り始めました
というわけで BP辞めちゃった わけなんですが、じゃあお前今なにやってんのよというのがこちらです。
http://www.gamecast-blog.com/archives/65644888.html
http://d.hatena.ne.jp/hotmiyacchi/20120204/1328376479
はい。ゲーム作り始めました。
なんでやねん！！！
これにはまぁ深いワケがあるのですが、話は去年の１１月ぐらいまでさかのぼります。この新会社の社長さんの 宮川さん という方と以前から個人的に交流があったのですが、ある日ちょっと話したいことがあるから来てくれと飲みに誘われまして。その席で、
「君のコードを見させてもらった。大変素晴らしい。実はこうこうこういう仕事をやることになって、君の力が必要だ！是非来てくれ！！」 （会話内容はだいぶ事実と異なります）
とラブコールをいただきまして。
で、実は宮川さんって
http://www13.atwiki.jp/game_staff/pages/125.html
聖剣伝説3とかFF11とかのメインプログラマやってるわけですよ。でまぁ私、聖剣3とか全キャラのエンディング見るまでやりこんだわけですよ。そんなゲームの作者の人に来てくれ！なんて直接呼ばれた日にはもう、そんなんホイホイついていくに決まってるじゃないですか。ってことで転職することになったわけです。あとは受託開発じゃなくて自社の製品を出していけるというのも決め手でした。iOS向けで自社の製品を出していける、それも冗談みたいなのじゃなくて普通に市場のトップを取れる可能性がある製品が出せるかもしれない、というのはものすごく魅力的に見えたのです。
■転職してからこれまでのあらすじ
ぶっちゃけると私はこの転職、最初ものすごく不安だったのです。というのも
- ゲームとかマジ作ったことない
- 3Dプログラミングとか一ミリもわからない、むしろ数学とかマジわからない
- ビープラウドがあまりにも良い環境だったし、給料もたくさんいただけたし、仲間も面白かったし、毎日勉強になりまくってたしで、正直転職先がこんなに恵まれた環境になるとは到底思えない
- 宮川さんのはてダ を見ていただければわかるのですが、基本的に彼はやたらとBlogに書く内容に誇張表現が多いので なんか嘘っぽい
そしたらたまげた。 新しい職場にはBPより頭がおかしい連中しかいなかったんですよ。
その日集まった18人全員のスキルがどいつもこいつもXMENだったと。当日の様子をお伝えできないのが非常に残念なのですが、一体全体宮川さんはこんな連中を日本のどこから集めてきやがった！！と叫ばざるを得ない。そしてまた彼のマネジメントのやり方が驚嘆するほどに上手いのです。以下ハイライト。
- いきなり初日からクライマックス状態の自己紹介タイム
- いきなり初日から会社でふぐちり鍋（注: 水曜日です）
- でも翌日朝９時出社は厳守させる、無断欠勤してきた奴にはものすごい勢いで怒る→全員超引き締まる
- いきなり２日目から「１日に１本ゲームの企画を立てて作る、４日連続で、チームメンバーは毎日全員入れ替え」という頭おかしい研修内容
- それを当たり前のようにクリアする全員、当然のようにiOS実機で動く
- それどころか毎日完成するゲームの質が上がる
- それどころか毎日完成したゲームのプレゼンの質が上がる
- ４日終了した段階で、全員の打ち解け度合いが半端ない、よくある「チームごとの壁」みたいなのが全くない状態で実際の仕事に突入
- 研修が終わった日にまた鍋（注: 一週間に二回鍋です、火曜日です、終電まで全員飲み食いしてます）
- でも翌日朝9時出社に誰も遅刻しない
- グラフィッカーさんに良いマウスがないか聞かれたのでSteelSeries XAIとSteelSeries 4HDの実物を持っていって触ってもらったら大絶賛され、翌日Xaiと4HDがそれぞれ８個ずつ届いた（注: 1セット1万2000円ぐらいします、たかがマウスです）
- 無線LANアクセスポイントの調子がわるいのでCISCOの良い奴にしましょうと答えたら、二日後に本当にCISCOのAPが届いた
- 開発用のMacツールおよび企画研究用のiOSゲームは全て買い放題
- 昼休みに社員8人程度でHaro Reachのデスマッチをプレイしてる
- 仕事上がりに同僚とCoDのcoopをプレイしてる
- 同僚にシャドウゲイトの話が通じる
- 同僚にPortal2やSkyrimやStarCraft2の話が普通に通じる
そして環境も素晴らしいですが同僚も皆とんでもない連中ばかり。スキルは当然として、全員が向学心と負けず嫌いの塊みたいなものですから、研修がとんでもなく白熱しまして、正直ヤバい。私もBPのハッカー魂と業務改善の魂を是非新しい職場に吹きこんでいこうと日々頑張っております。当分の間は退屈しない、全力全開の日々が過ごせそうです。
2012年2月8日水曜日
ビープラウドを退職しました
やや旧聞になりますが、１月末付で 株式会社ビープラウド を退職いたしました。知ってた人はすでに知ってたと思うんですが、なんかすっごい唐突で色々とすみません＞＜ 退職理由や次の仕事の話などは次の投稿に詳しく書く予定ですのでそちらに任せるとして、今回はこの場をお借りしましてビープラウドがどういう会社だったか、ちょっと過去の振り返りなどをしてみたいと思います。
■BPはどんな会社か
（良い意味で）頭おかしい連中ばっかりが集まって、本気で学び本気でコード書いている集団だと思います。
具体的には 右隣の奴 が常時こんな状態で仕事してます。
こんなことを書くと本当に変人しかいないんじゃないのか、お前ら大丈夫か、などと思われてしまうのですが、そうじゃないんです。ビープラウドはみんなが自分のすべてをぶつけて、さらけ出して仕事できる素晴らしい会社なんです。私は新卒で入社したSIerの会社をやめてBPに入社したのですが、入社した初日にパスワードが失われてログイン出来ないMacを渡されて何とかハックして使えという具合だったり、それまで同期の誰に喋っても通じない技術の話が当たり前のように通じたり、っていうかむしろ私が知らない事のほうがはるかに多かったりで、全力で自分の技術をぶつけることができた感動を今でも覚えています。世の中にはいろんなくだらない理由だとか社内政治だとかで、自分の全力、技術力のすべてを出し尽くせない、出してはならない、出す価値もないような仕事が散見される（それが最初の会社をやめた理由の一つでもある）のですが、ビープラウドでは全力全開超推奨。二年間で vの人 から「お前は随分良くなった」とお褒めいただけた程度には成長できたのも、間違いなくビープラウドで自分の全力を出して挑戦し続けさせていただいたおかげだと思っています。
私が見たビープラウドの感想なので、他の人から見たらちょいとズレているのかもしれませんが、私は技術を大事にする、エンジニアを大事にして全員にMacやらレッドブルやらを支給する、社内勉強会やBPStudyを開催する、などといったBPのハッカー文化が大好きで、退社した今でもその気持ちは変わりありません。むしろ退職して新しい仕事をしている今から振り返ると、BPの素晴らしかったところはあのハッカー文化だったんだなという思いを強くしています。
■謝辞
去年の１２月にいきなり辞めると言い出したにも関わらず快く送り出していただいた社長のはるおさんとCTO、超ムチャぶりにも関わらず私の仕事を引き継いで立派に締めてくれたgkt、個人的に超いろいろ迷惑をかけまくった右隣の席の奴に、ありがとう！！むしろBP全員ありがとう！！！お陰様であきすては元気にやってますよ！
2012年1月29日日曜日
xxd を使って画像などのバイナリデータをソースコードに含める方法
iOS向けのライブラリやフレームワークを作成しているときに、どうしても画像などのバイナリデータをライブラリやフレームワークに含めたくなる時があります。たとえばUI系のフレームワークなどですね。このようなときに、たとえば静的ライブラリ（.aと.h）やフレームワーク（.framework）とセットで画像を一緒に同梱し、ユーザーのXcodeプロジェクトに一緒に含めてもらうという方法もあるのですが、この方法だと画像名がユーザーのプロジェクトに含まれている画像とかぶったりしてはいけませんし、管理が面倒になってしまいます。また、ライセンスがプロプライエタリなライブラリでは、画像などのリソースをあまり積極的にユーザーに公開したくないというニーズがあったりします。
そこでxxdツールのご紹介です。岸川先生に教えていただいたのですが、xxdというツールを使えばバイナリデータをC言語のヘッダファイルとして簡単に出力することができるらしいのです。これを使ってバイナリデータをライブラリ内部のソースコードの一部として配布してみましょう。
xxdはvimに同梱されているので、最初からMac OS Xについてきます。使い方も非常に簡単です。
そこでxxdツールのご紹介です。岸川先生に教えていただいたのですが、xxdというツールを使えばバイナリデータをC言語のヘッダファイルとして簡単に出力することができるらしいのです。これを使ってバイナリデータをライブラリ内部のソースコードの一部として配布してみましょう。
xxdはvimに同梱されているので、最初からMac OS Xについてきます。使い方も非常に簡単です。
xxd -i Sample.pngとすると、
unsigned char Sample_png[] = {
0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d,
0x49, 0x48, 0x44, 0x52, 0x00, 0x00, 0x07, 0xfd, 0x00, 0x00, 0x04, 0x73,
//中略
unsigned int Sample_png_len = 589903;このような感じでバイナリデータがC言語のヘッダファイルになって出力されます。あとはこれをNSDataにして、UIImageを生成することができます。NSDataを作る際には余計なデータコピーが発生しないdataWithBytesNoCopy:length:freeWhenDone:を使うことをお勧めします。NSData *data_Sample_png = [NSData dataWithBytesNoCopy:Sample_png length:Sample_png_len freeWhenDone:NO]; UIImage *image = [UIImage imageWithData:data_Sample_png];
2012年1月24日火曜日
Jenkins を iOS アプリ開発に導入してみた (gcov編)
前回 はSenTestKitに続いてGHUnitを導入して、Jenkins上でGHUnitによるテストの自動実行を行いました。今回はさらにステップアップして、gcovを使用してコードカバレッジを取るようにしてみようかと思います。
■gcovを使ったコードカバレッジの取得（Xcode 4.3版）
Xcode 4.3の場合は以下の参考ページで紹介されている方法がオススメです。実機ででもシミュレータでも動作してお得です。
http://www.cocoabuilder.com/archive/xcode/314794-xcode-4-3-moved-libprofile-rt-how-to-reference-it-now.html
http://www.infinite-loop.dk/blog/2012/02/code-coverage-and-fopen-unix2003-problems/
https://github.com/InfiniteLoopDK/ILTesting
- Generate Test Coverrage FilesとInstrument Program FlowにYESを指定する
- http://www.infinite-loop.dk/blog/2012/02/code-coverage-and-fopen-unix2003-problems/で紹介されているILProfilerCompat.cを組み込む（これによってfopen$UNIX2003によるエラーを防ぐ）
■gcovを使ったコードカバレッジの取得（Xcode 4.2版）
【2012/03/15追記】こちらの方法はXcode 4.2が前提となっており、Xcode 4.3以降は動作しません！
gcovとはgccに付属されているC言語用のカバレッジ測定ツールです。これを使うことで、C言語と、その拡張であるObjective-Cのコードカバレッジをバッチリ取得することができます。ということで早速プロジェクトに組み込んでみましょう。幸いにしてすでに先駆者の方がいらっしゃいました。
http://tech.naver.jp/blog/?p=706
基本的に上記に記載されている通りの手順で導入すれば簡単にgcovによるコードカバレッジの取得ができますが、実際にやってみたところ幾つか補足があるので追記します。
先ほど紹介した記事では/Developer/usr/lib/libprofile_rt.dylibの追加と-lgcovの指定両方を行なっているのですが、私が試したところどちらか片方だけで成功するということがわかりました。具体的には以下のとおりになります。
1. /Developer/usr/lib/libprofile_rt.dylibを使うパターン
2. -lgcovを使うパターン
それぞれ見ていきます。
1. /Developer/usr/lib/libprofile_rt.dylibを使うパターン
/Developer/usr/lib/libprofile_rt.dylibをプロジェクトに追加し、Other C Flagsの-fprofile-arcs -ftest-coverageを設定すればOKです。それ以外の手順は必要ありません。
このパターンですとスムーズにgcovの結果を出力することができましたが、残念ながらこの方法はSimulator上でしか使用できません。というのも、/Developer/usr/lib/libprofile_rt.dylibがそもそもarmv6, armv7用のバイナリを含んでいないという問題があるのと、ライブラリ探索パス"/Developer"以下がDeviceビルド時に勝手にiphoneos.sdk以下の/Developerに置換されてしまうため、ビルド時にlibprofile_rt.dylibをリンカが発見できずエラーになる問題があるためです。基本的にSenTestingKitのようなSimulatorでしか実行しないビルドターゲットでやるのが良いと思われます。
2. -lgcovを使うパターン
参考: http://stackoverflow.com/questions/5101014/code-coverage-not-showing-results-using-xcode-gcov/5140459#5140459
-lgcovをOther Linker Flagsに追加し、Generate Test Coverrage FilesとInstrument Program FlowにYESを指定すればOKです。それ以外の手順は必要ありません。
このパターンですとlibgcovはarmv6, armv7でも動作するので実機でのカバレッジ取得ができるのですが、問題はそのままの設定でビルドして実行すると実行時にクラッシュします。これはlibgcovが実行時にカバレッジデータを書きだす際に、デフォルトの設定ではiOSのサンドボックスの外にアクセスしようとするため書き出しに失敗してしまうのが原因です。したがって上記参考URLに従ってGCOV_PREFIX環境変数を使いサンドボックス内部にカバレッジデータを書きだすように指定してやる必要があります。
この方法は環境変数を実行時に設定する必要があって面倒なのと、カバレッジデータが書き出される箇所がJenkinsのビルドディレクトリの中ではなくiOSシミュレータまたは実機のサンドボックスの中になってしまうため、Jenkinsからカバレッジの取得を行うのが困難になってしまう問題があります。
今回は1. のパターンを採用し、SenTestingKit上でSimulatorビルド時のカバレッジ取得だけを行うことにしました。GHUnitでも実機上での動作を諦めれば問題ないのですが・・・まだ課題が多い感じですね。
ビルド設定ができたらビルドして、きちんとgcovコマンド経由でカバレッジが取得できていることを確認しましょう。
■gcovrを使ってCoberturaのXML形式に変換する
gcovのカバレッジデータの取得ができるようになったら、今度はJenkinsと連携させるために、gcovの出力をCoberturaというJava環境のカバレッジ計測ツールの出力するXML形式に変換する必要があります。これはJenkinsがgcovのカバレッジデータ出力の集計に対応していない為です。っていうかgcovの出力は単なるタブで区切られた文字列で人間以外にはとても優しくないので集計ができないのです。
ここで、Python製のgcovrというツールをJenkinsサーバマシンに導入します。 gcovrをgcovの代わりに使うことで、CoberturaのXML形式で結果を出力できるようになるほか、カバレッジ計測対象となるファイルを簡単にフィルタリングできる（たとえばテストケースクラスのカバレッジなんか集計してもしょうがないので除外するなどできる）のが大きな魅力です。
http://wiki.hudson-ci.org/pages/viewpage.action?pageId=45482230
https://software.sandia.gov/trac/fast/wiki/gcovr
インストールはMacマシンであれば非常に簡単で、以下のコマンドを打つだけです。
sudo easy_install gcovrインストールが完了したら、あとは
gcovr --xml --output=cobertura-report.xml build/とかやれば一発でbuildディレクトリ配下のすべてのカバレッジを計測結果を集計してXML形式で書きだしてくれます。
ここでもし、テストケースのカバレッジは除外したいなどという要件がある場合は、
gcovr --xml --exclude=".*/.*Test(s)?\.[(c)(cpp)(m)(mm)]" --output="cobertura-report.xml" build/などとすればOKです。
■JenkinsのCoberturaプラグインを使って結果を集約する
CoberturaのXML形式で結果が取れるようになってしまえばあとは楽勝です。JenkinsにCoberturaプラグインをサクっとインストールして、
https://wiki.jenkins-ci.org/display/JENKINS/Cobertura+Plugin
あとは以下のようにJenkinsのジョブ設定を書いてしまうだけです。先述の通り、SenTestingKit上でSimulatorビルド時のカバレッジ取得だけを行いたいので、既存のSenTestingKit用単体テストジョブのXcodeビルドの後でgcovrを実行するシェルスクリプトを実行してやれば一発です。
カバレッジが取れるようになると断然見栄えがしますね。
登録:
投稿 (Atom)