Sorry, this entry is only available in 日本語.
Tag Archives: Kent Beck
テスト駆動開発でテストを先に書く手順
参考書籍は Test-Driven Development By Example、 日本語版は テスト駆動開発入門です。
今回読むのは Section III のところです。 テスト駆動開発のパターン について書かれています。
Isolated Test
Test の独立性についてですが、 Kent Beck は過去の経験から次のように綴っています。
First, make the tests so fast to run that I can run them myself, and run them often. That way I can catch errors before anyone else sees them, and I don’t have to dread coming in in the morning. Second, I noticed after a while that a huge stack of paper didn’t usually mean a huge list of problems. More often it meant that one test had broken early, leaving the system in an unpredictable state for the next test.
続けて書かれていますが、 ひとつの問題が発生した場合に失敗するテストはひとつであるべきです。 問題の特定を楽にするために。
そんな独立性の高いテストを作る手頃な方法として、 “実行順序に依存しないテスト” が挙げられていますね。
テストを書く前に ToDo List
Kent Beck は彼の経験から、 目的を達成するためには (プログラムで実現すべきことを実現するためには) やることを全部書き出すというのがいい と結論づけています。 Money Example
の中でも ToDo List を作っていました。
ToDo List のメンテナンスにも注意が必要です。 Kent Beck は新しい ToDo が増えたとき、 既存の ToDo 含め 次の3つのカテゴリに分けます。
- いまやる
- あとでやる
- できなくてもいい
テスト駆動開発において ToDo List に書かれるのは Test として実装するべき事項です。 具体的には Section I
の Money Example
に載っていたものです。
ToDo の書き方
Kent Beck は 大変丁寧なことに、 ToDo の書き方まで説明してくれています。 これは早く実践していきましょう。
- 考察が必要な項目については “???” をつける。
- すぐに実装に取りかかれるように書く。
- 実装が必要な演算についてテストケースを書く。
- もし実装前の演算であれば、 その演算の null version (特殊な場合) のテストケースを書く。
- 必要だと思うリファクタリングをリストアップする。
なぜテストを先に書くのか
Kent Beck はテストを先に書く理由について、 次のように書いています。
- コードを書くプログラマとしてのゴールは機能追加であってテストを書くことではないため、実装の後(目的達成後)にテストコードを書くことはない。 (目的達成後にテストを書こうと思わない。)
- (コードの)デザインについて考える時間が必要。
- スコープを制御するためのメソッドが必要。 ここでいうスコープは、後のページで詳しく説明が出てくるが、要するにテストを順次グリーンにして、今実装すべき機能(スコープ)を整理するということ。
確かに、 実装が先に終わってテストがおまけになってしまう、 そんな経験が多々あります。 更に Kent Beck は テストのモチベーションのサイクルについても言及しています。 テストのモチベーションは開発者にとって一番大事かもしれません。
Readers who viewed this page, also viewed:
テスト駆動開発で使う テストフレームワークの仕組み
参考書籍は Test-Driven Development By Example、 日本語版は テスト駆動開発入門です。
Money Example の次は jUnit のようなテストツールを作ってみるお話です。 30以上の言語で使われている xUnit は、 今や巨大な資産ですが、 そういったものは自分で作れるものなんでしょうか。
テストフレームワークの仕組み
読んでみると、実際にやっていることは難しくなさそうです。 肝となるのは 一連のテストの結果 (実行・成功・失敗したテスト数) をどうやって保持するかではないかと思いました。 独自にテストフレームワークを作るときに役に立ちそうです。
社内でも独自にテストフレームワークを作っている人がいます、 かなりシンプルにできるそうです。 その人によると、 PHPUnit などのテストフレームワークは いろんなファンクションや機能をつけているから複雑になっているそうです。 そうじゃないと使ってもらえないからだとも言っていましたが。
JUnit や PHPUnit は TestCase だったかのクラスを継承してテストコードを書いていくので 今回説明されていたやり方と同じですね。 でも rspec だと describe で書き始めたりするし クラス の 定義 で始めるわけでもないので 本書とは別のアプローチかもしれません。
Readers who viewed this page, also viewed:
テスト駆動開発でテストを書かない場合がある
参考書籍は Test-Driven Development By Example、 日本語版は テスト駆動開発入門です。
機能追加の方針
Franc-ly Speaking
のところ(29ページ)からです。 Franc を導入して複数通貨に対応させるんですね。 39ページに至るまでの流れを見ていくと次のようになります。
Dollarを複製する。 テストコードも複製する。- 親クラス
Moneyと 継承クラスDollar,Francに分ける。 - Factory Method Pattern で
Moneyクラス に共通のものを集約する。
Dollar から Money へ、 子クラスから親クラスへメソッドを移す手順には要注意ですね。
書かないテスト
途中、 toString() というメソッドを、テストコードを書かずに追加しています。 この判断基準は重要なのでまとめておきます。
次の条件を満たす場合は、テストコードを書かなくてもOKとします。
- 画面上で(テストの)結果を見ようとするメソッドを追加しようとしている。
- 追加するコードはデバッグのためのコードで、仮に正常に動かなくなったとしてもダメージが小さい。
- テストが Red で終了している。 (Red のときは新しいテストコードを書きたくない。)
普遍的にまとめた記述が今のところ出てきていないので toString() 追加の際の説明をまとめたものになっています。
toString() 程度 だったらテストを書いてもよさそうですが、 もっと複雑なものに成った場合には テストを書かずに進めた方がいいんでしょうか。 これは実践あるのみですね。
その後 Money Example
の演算の実装と、 全体を俯瞰した傾向、 テストの品質について重要な記述がありますが、 ひとつひとつ紹介すると長くなるので割愛します。 でもひとつだけ気になる記述があるので紹介します。
Easy to read for programmers – Unsynchronized documentation is scarce. The tests will be more valuable if they are readable, giving an interesting second perspective on the messages hidden in the source code.
テストを書けば仕様も理解しやすくなるかもしれないと思いました。
Readers who viewed this page, also viewed:
テスト駆動開発の始め方
約70ページにもわたって MONEY EXAMPLE という事例が書かれています。 あまりに多いので一気に読むのはちょっと辛いですが、テストドリブンを夢見てがんばって読んでいます。 今回は テストドリブンの序盤となる部分をyんでみました。
実装の前にテストをすべて書くのは無理
MONEY EXAMPLE のところを見ると、 Kent Beck ですら最初にすべてのコードを書かないということがわかります。 MONEY EXAMPLE で取り上げられている単純な金額の掛け算でも、コードが徐々に完成していくのにつれてテストコードも変わっていきます。 よく、最初にテストコードを書くなんて無理だからテスト駆動開発は無理だという人がいますが、テスト駆動とはそういうことではないんですね。
MONEY EXAMPLE では、 存在しないクラスを使ってテストを書き始めます。 Red どころか コンパイルすらできないテストを書くところから始めています。 必要なクラスを考えてクラスのテストから書き始めるのかと思いましたがそうではありませんでした。 最後の理想形をテストに書いていました。
テストドリブンの手順
ToDo の整理をしてからテストを始めます。 この ToDo List はコードが完成するまでついて回ります。 載っている事例では、 存在しない Dollar クラス を使ってテストを書くところから始めています。 そして テストを通してできるクラスのメソッドは(最初は)あくまでスタブです。
MONEY EXAMPLE は次のようにして進めていました。
- テストを書く。存在しないクラスも使ってよい。
- テストをコンパイルできるようにする。
- テストを Green にする。
- リファクタを行い、重複を取り除く。
テストを Green にする方法
- 固定値を返すなどして、テストを通るようにする。 (実装コードとしては完成ではない)
- 明らかにわかるコードを実装する。
- 複数の側面からのテストを書く。 (Triangulation)
Triangulation というのは、 テストケースを追加することで固定値での返り値を返せないようにするように、複数のパターンのテストを書くことで実装コードを規定していく方法です。 たとえば 1 から n までの総和を求める関数があったとして、 Sum(1) == 1 だけだったら Sum の返り値は 固定の 1 でもいいですが、 Sum(5) == 15 だと実装せざるを得なくなります。 Kent Beck は本当にどのようにリファクタすればよいか迷うようなときに Triangulation を使うそうです。 どうすればいいのかわかっている場合は Triangulation のためのテストコードは書かれません。
MONEY EXAMPLE の中で出てきた Value Object というのも重要だと思うのでまとめておきます。
Value Object
一種のインスタンス変数で、コンストラクタで設定された値はそれ以降変わることがありません。 これにより、ポインタを通じた意図しない値の書き換えの発生を防ぎます。 別の言葉で書くなら 副作用対策です。
Value Object の持つメソッドの戻り値は必ず新しいオブジェクトにします。 下に例を書きました。 Num の add メソッドの戻り値は新しいインスタンスになっています。 これにより add の前後で Num のインスタンスは変更することがありません。 また、 primitive value ではないので、 別途 equal メソッドを実装しておかないとテストコードを書くときに困ることがあります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
class Num def initialize(amount) @amount = amount end def get_amount return @amount end def add(num) return Num.new(get_amount + num.get_amount) end def equal(num) return get_amount === num.get_amount end end |
Test-Driven Development By Example の JAVA のコードをまねて作ったのですが、 言語が ruby なので実践的には get_amount を書かずに attr_reader :amount と書きますね。