20150715 『続・断捨離』TDDの心得編

『続・断捨離』～ TDD 実践＆心得編～

Natsuki Nishino

TestDriven

Development

テスト駆動開発

TDD は

『動作する、キレイなコード』

を目指す手法のひとつ

動くコードって？

普段書いているコードは

大半が動いているハズ( ・ _ ・ ;) ﾃﾞｽﾖﾈ ?

キレイなコードって？

バグ対応や改修が簡単にできる！

実装者の意図がわかる！

変えてみたらアレ… ?( ・ _ ・ ;)

が起きにくい

仲間や明日の自分がなんだこれ… ( ； ´Д

｀ )って

頭を抱えないコードのこと

まず動くようにしてからキレイにお掃除する

キレイに変更していく間に“壊していないこと”は

テストコードが担保するコレが TDD

どうやってやるの？

1.目標を考える2.その目標を示すテストを書く

3.実行して失敗させる (Red)4.テストを成功させるコードを書く (Green)

5.テストの成功を維持したままリファクタリングする

6.1 ～ 5 を繰り返す…

ここまで前回のあらすじ

詳しくは Web で

TDD をやること自体は

目的ではない

TDD の目的はテスト自動化でもな

い

仕様通りに動いてキレイなコードを目

指す

TDD の心得

• 1 歩ずつ、少しずつ•素早く、とりあえず動かす•同時に複数を相手にしない•自分が最初のユーザーになる•テストは動くドキュメント• TDD はスキル


1 歩ずつ、少しずつ

一気にやるとどこで踏み外し

たかわからなくなる


動くかなぁ…

✕

不安をテストに

動かしてみる

まだ動かないコードより

動いているコードに価値がある

動いていればバグが見つかる

キレイに動くように

設計にキリがなくなる

キレイに動くように

並行で書くのは相当なスキルが必

要

同時に 2 つ考えるのは大変


複数のテストを同時に書かない

テストコードとプロダクトコードを

同時に書かない

書いたテストが成功するまで

次のテストは書かない

書いたテストが成功するまで

次のプロダクトコードも書かない

複数同時に考えると混乱しやすい

テストコードにミスがあったら気付くのが遅

れる

✕

タイマン勝負


そのメソッドの使い方を

テストに表現する

もし使いづらくても早い段階で気付ける


コードの仕様を動作を持って表現す

る

メソッドの使い方を動作を持って表現す

る


✕

練習すれば上達する


ちょいテク

テストは動くドキュメント

テストは動けばそれで OK ？

// テストパターン 1public void test_1()…// テストパターン 2public void test_2()…// テストパターン 3public void test_3()…

何を確認したいテストなのか、コードをじっくり

読まないとわからない

テストもリファクタリングでき

る

メソッド名を日本語で書いちゃう

@Testpublic void testGetLargeNum_ 第 1 引数が大きい () { TwoNumber twoNum = new TwoNumber(6, 2); assertThat(twoNum.getLargeNum(), is(6));}

期待値も書いちゃう

@Testpublic void testGetLargeNum_ 第 1 引数が大きい _ 第 1 引数を返す () { TwoNumber twoNum = new TwoNumber(6, 2); assertThat(twoNum.getLargeNum(), is(6));}

全てのテストの共通処理

@Beforepublic void before() { System.out.println(“ テストメソッドはじめるよ");}

@Afterpublic void after() { System.out.println(“ テストメソッドおわったよ");}

全テストの最初と最後の処理

@BeforeClasspublic static void beforeClass() { System.out.println(“ テストはじめるよ ");}

@AfterClasspublic static void afterClass() { System.out.println(“ テストぜんぶおわったよ ");}

パターンテストもお掃除できる

@DataPoints で宣言したデータで@Theory のシナリオを実行する

テストシナリオ

テストパターン

( ･ `ω ･ ´)b

1 つだけ失敗したときにどれが失敗したかがわかりにくい

テストコードのテストコードは

プロダクトコード

テストのリファクタリングと

同時にプロダクトコードを変えてはいけない

断捨離の心得

継続することが大事♡

コピペやっつけ

動くからいっか…

時間がない変えるのが怖

い

TDD をやると書くコード量は増え

る

But ！

かかる時間はそんなに変わらな

い※当人比です。

動いてキレイなプロダクトコードが

できる

改修が簡単なコードになる

コピペやっつけ

動くからいっか…

時間がない変えるのが怖

い

計画的に、継続的に

ﾊﾞｲﾊﾞｲ (^_^)/~れがしーこーど

20150715 『続・断捨離』TDDの心得編

Engineering