2015年03週目まとめ

Jenkins ユーザ・カンファレンス 2015 東京

参加しました
Workflow Plugin等を導入したいのですが、
現在クリティカルパス上の作業をしているために手が回りません…
運用コストを下げられるので是非入れたいのですが、
どうしても優先度は下がってしまいますね…

Tumblrのgolang用ライブラリ

見当たらなかったので作成中(まだ何も動きません)
https://github.com/ota42y/go-tumblr

goのテストは特殊なフレームワークとか作らずに、普通にコードとして書くのを推奨しているそうです。
rspecとかで専用のフレームワークにそって作るのとは大違い。
書くのは面倒だけど、フレームワークの知識が無くても大丈夫というのは良いかもしれません。

フレームワークの学習コストとそれによって得る効率化と、使わないことによる効率の低下とどっちが得なのでしょうか。 あと外部APIなので秘密情報をどうやってテストの時に設定するかが課題です。
毎回書いては消すのはとても面倒なので…

UIと強結合しているテスト

cocos2d-xを使ってiPhoneアプリを作成していると、ゲームUIでTDDとかするのは実質不可能ではないかなと思います。 これはおそらくUI層の正しさが、状態に強く依存するのが原因です。

ボタンを配置してタッチで特定のメソッドを呼び出すような場合、
ボタンが画面上に表示されるかは、他のよりZ座標が大きいオブジェクトと被さっていないかをチェックする必要や、
より優先度の高いタッチオブジェクトが存在しないかといったことをチェックする必要があります。
さらに、演出中は表示されるけどタッチは出来ないなど、その部分以外の所の状態によって結果を変える必要があります。

つまり、新しいボタンを配置するためには様々な状態のテストを作成し、
かつほかのオブジェクトに対して新しい状態を追加することになるため、テストの変更がとても大きくなります。
そのため、UI層でテストをする場合、作成・維持ともにとても大きくなっていくため、
完全に不可能ではないですがコストか高く、現実的に出来るものではありません。

ただし、UIコンポーネントについて個別にテストするのは有効だと思います。
例えばボタンクラスであればタッチした時に、コールバックが呼ばれるか、範囲外の時に呼ばれないか等です。
ただし、UIを作る際に個別にクラスを作ることはそんなに多くなく、
多くがコンポーネントの配置と、その画面専用ロジックとのつなぎになるため、大きな効果は見込めなさそうです。

なお、ゲームはそもそも共通で使う部分が少なく、画面内の状態がとても多いという前提があります。
例えば通販サイトではヘッダーやサイドバーは共通で使い、メインの部分とは独立していますし、
メインの部分も商品データが違うだけでテンプレートは同じといったように、共通で使う部分が多いので、
そのような部分のテストは有効ではないかと思います。