Skip to content

Frontier Blog

for more efficient software development!!

Archive

Category: Scrum

本エントリは「TDD Advent Calendar 2013」の参加エントリです。

@t-wadaさんの最近行ったTDDの講演や寄稿についてに引き続きの記事を書かせて頂きます。

僕がTDDを実践しようと思い始めてからの日は浅く、ちょうど1年くらい前からになります。
そのきっかけとなったのが、Certified Scrum Developerの研修でした。
この1年、TDDの実践を1つのテーマとして仕事をしてきましたが、一度、初心に帰って見つめなおす意味も含めて、Certified Scrum Developer研修におけるTDDで印象に残っていることをまとめてみます。

テストは1秒以内に実行可能にする

頻繁にテストを実行するため、時間のかかるテストは開発中にテストを実行しなくなる。
実行しないテストを開発者は記述しなくなる。

テストを書く領域にもよるとは思いますが、意識しないで書くと、少し時間のかかるテストを書いてしまっていることはあるかなと思います。そして、これを実現するためには、

テストでは外部アクセスしない

テストはデータベース、ネットワーク、ファイルシステムなどにはアクセスしない。

話を最初に聞いた際には、かなり強力な制約と感じました。
しかし、この1年、なるべくこの原則に沿うように試行錯誤した感想としては、理想論を言うのであれば、この原則を守るにこしたことはないと感じています。

Webシステムのフレームワークなどでテストの仕組みをサポートしているものでは、実際にフィクスチャとして、データベースにデータを格納して、それを利用したテストを書くものも少なくないと思います。
このような仕組みでテストを書いてもよいのですが、テストのセットアップが煩雑になったり、テストコードと別の場所にフィクスチャを管理する必要があったりとで、テストコードだけを見た際の表現力が下がりがちなのが、その理由です。

じゃあ、どうするということで登場するのが、

Mockを効率的に使う

研修では、JMock2やJMockitを使いました。
慣れるのにも時間がいるとは思いますが、これが非常に強力ということを強く感じました。

Mockを効率的に使うことで、テストがシンプルになり、自己完結するようになります。
また、こちらの和田卓人さんのCodeIQの記事において、「現在時刻へのアクセスを行うインターフェイスを抽出」というところで自分が書いたコードを取り上げて頂いたのですが、Mockを意識することで、オブジェクトの責務がより明確で単純になるという設計技法としてのTDDの効果も促せるのではないかなと思います。

次に、よく自分がやってしまうことへの自戒として、

熟練のクライマーは手と足を同時に動かさない

僕自身、「テストコード実装」→「プロダクトコード実装」→「リファクタリング」というサイクルの中で、リファクタリングの際に、よくテストコードとプロダクトコードを同時に修正してしまいます。
そして、よく意識が発散して、破綻します。

今は現状のテストコードで、プロダクトコードのリファクタリングをしているのか、あるいは、プロダクトコードが完成したから、テストコードのリファクタリングをしているのか、それを明確に意識すべきですね。

また、これと関連して、

プロダクトコードとテストコードではリファクタリングの意識が少し違う

基本的には質の高いコードを保つという意味では、プロダクトコードとテストコードにリファクタリングの違いはないです。ただし、目的が違うコードなので、質の意味が違います。

実際に研修では、ある日にコードの重複があるから、リファクタリングしなきゃいけないよという指摘を受け、それを踏まえて、コードの重複をどんどん削除しました。テストコードにも、複数のテストケースで共通するような初期化のコードがあったので、それを一箇所にまとめました。
すると、翌日、頑張って重複を除去してくれたのは分かる。でも、このテストの初期化の部分のテストコードは、結果の検証と対応しているから、の敢えて重複を許容することで、テストコードの意図が明確になるという指摘をもらいました。

以上、研修のテキストを見ながら、思い出しつつまとめてみました。
どれも基本的なことだとは思いますが、何かの参考になれば幸いです。

次は、blacさんのMSTest‐Windows ストア アプリ開発の暗黒大陸になります。

ついに最終日。

とても興味深い5日間だった。そして、色々とやりたいことが見つかった5日間だった。

1つ言いたいことは、Scrumを使った開発をやりたいと思いつつ、うまくできないと思っている人には、是非、受けてみて欲しい。

英語力とか、そんなことを気にせず、受ける価値のあるものだと思う。

 

 

3日目からは、研修の内容が大分開発に集中するようになってきている。

とはいうものの、Jenkins、Jetty、Tomcat、Mavenと戦っていたと言えるかもしれない。

何より、今日はテストがパスしない状態でいることの苦痛をすごく感じた。

 

赤い画面を常に見せつけられて、パニック!パニック!と言われると、焦りますね。

 

同時に、グリーンに戻ったときの安堵感というか、居心地の良さは大きいですね。

グリーンが当たり前なのかもしれませんが。

 

そんなこともあって、今日はペア作業といいつつも、ペアを超えてガヤガヤやっていた気がする。

 

あとは、スプリントプランニングパート2というか、タスクの管理のやり方は工夫の余地があるかもしれない。

言葉で各タスクの内容で合意はとっていたつもりでも、実際にやってみると、それに関する小さなタスクが出てくることが多い。

そのタスクで行うか、新しいタスクで行うか。

 

今日、はまったのは、複数のTestSuitesで、Start Selenium Serverを実行すると、うまく行かない。

ブラウザを使ったテストは、1つのTest Suiteにまとめるのが一番なようだ。

今回の参加者は、中国人1人、タイ人1、日本人1人(自分)を含む7人でした。

 

スキルや知識がまちまちの状態で、コンセンサスをとることはとても難しいと感じた1日でもありました。

また、自分の英語のスキルがもどかしく感じた1日でもありました。

 

思い返してみると、今日は何をしたのだろうという感じでもあるのですが、きっとスクラムチームを立ち上げた際に陥りがちな問題をいくつも経験できた気がします。

一言で言うならば、今日はとてもよい素振りが出来たという気がします。

CSM研修

11月 14

念願だったCertified Scrum Master研修を受講しています。

朝9時から夕方18時までの長丁場と思っていたのですが、驚くほどあっという間に時間が過ぎてしまいました。

 

Agile関連の集まりに顔を出させてもらう時によくあることですが、頭では分かっているつもりになっていることを、改めて目の前に用意されて分かっていなかったことに気付かされる。そんな内容でした。

今日の内容を一言で表すのであれば、

「プロフェッショナルなソフトウェアには勇気が必要」

ということでしょうか。

 

Scrum道 Expo 2012に参加して来ました。

 

一言でいうのであれば、ある種憧れな人が一杯いて興味深かったという感じです。

たくさんの発見があったけれども、そのいくつかを挙げれば、

 

ペアワークは是非導入していきたい。

人のコンテキストで問題をみると、次に進んだらよさそうな方向性が見えるのに、ほとんど同じような問題でも自分のコンテキストで発生すると、その問題をとらえられなくなってしまうことに気が付いた。

自分が考えている方向に進もうとしている人がこんなにいるんだということを実感できた。正確に言えば、多くの人が進もうとしている方向に自分も進もうとしているのかもしれませんが。
とにかく、コミュニティの力を感じた一日でした。