C# から java へのプログラム移植で体験したtddの効果は？

C# から Java へのプログラム移植で
体験したTDDの効果は？
TDD超入門者、 Java 超初心者が体験したパラダイムシフト
2013.01.19 CLR/H#78

@furuya02

copyright© 2012/01.. by SAPPOROWORKS

自己紹介

 ハンドル SIN／古谷誠進
 Twitter @furuya02
 仕事某社でシステムサポート

札幌ワークスというホームページを中心に、フリーソフトや
技術情報を発信させて頂いております。

本日の内容

１．定義
２．ＴＤＤへの階段
３．BlacｋJumboDogのC#からJavaへの移植
４．私のテスト紹介
５．テストについて説明してみる


１．定義
テストとは
開発終了とは


（ユニット）テストとは
特に１・２象限のテストは、要求仕様や設計のテストを目的とする

ビジネス面手動

(２象限) (３象限)

チプロトタイプ探索製
ーシュミレーションユーザビリティ品
ム評
支価
援 (４象限)
（１象限）
単体テストパフォーマンス
コンポーネント負荷
セキュリテイ
自動
技術面

実践アジャイルテスト「アジャイルテストの４象限」より

ユニットテストで品質保証はできない
QAは別に実施される必要がある

 QA「ソフトウェアの品質評価テスト」とは違う
 TDDにおけるテストは、仕様把握・分析設計のため
 グリーンの時は、あくまで設計どおり動作しているという
意味
 顧客が望むとおり動いている保証はない（仕様バグ）
 「保守性が高い」「変更に強い」「リファクタリングしやす
い」という意味では、品質向上にはなると言える


（プログラムの）開発終了とは？
納期・・・・？

その使用が終了する時
「納品時」や「バグ出しが終わった時点」ではない

 動いているコードは触るな <= これでいいのか
 綺麗にリファクタリングされ、いつでも変更可能 <= 理想的
 スパゲティがカオスになって、手が付けられない <= 終焉
 プロトタイプやその場限りで使用するツールは、それなり


２．ＴＤＤへの階段
私の場合・・・・限りなく遠い道のり


TDDへの遠い道のり
何年もかかるという意味ではないです。人によっては瞬殺かも・・・
完成期
TDD・CI

私・・・今この辺のような気がしてます第４期（パラダイムシフト）
テストのリファクタリング

第３期（練習）
どんどん書きたくなる
テストカオスに陥る
第２期（入門）
とりあえず力づくで
書いてみる
第１期（圏外）
必要性が全く見出せない。でも気になる・・・・

第１期（圏外）
気にはなっている・・・・・

キッカケ
「リファクタリング」初版２０００年６月
状態
リファクタリングは、積極的にするようになったが・・・
テストは書いてない。デグレだらけ
どうやって書けばいいか全然分からない
しばらく、ここ状態から抜け出せない

今、読みな直してみると、既に、分かりやすく説かれていた・・・・

リファクタリングプログラムの体質改善テクニック
マーチンファウラー著

第２期（入門）
ちょっと流行ってるみたいだし・・・・

キッカケ
巷で、ちょっと流行って来たから
読んだらできそうな気がした
「俺、テスト書いてるぜ」的な
状態
試行錯誤
力ずくでどんどん書く
※C#版BlackJumboDogへのテスト追加

レガシーコード改善ガイドテストがないコードはレガシーコードだ！
マイケル・C・フェザーズ著

第３期（練習）
いよいよ、私もテストファーストかぁ

キッカケ
デグレの早期発見で嬉しくなる
後から書くことに限界を感じる（面倒、結合性）
状態
テストファーストへの挑戦が始まる（やっとＴＤＤ入門）
設計に変化が生じる
大胆なリファクタリングが気前よくできる
※BlackJumboDogのJava移植開始


第４期（パラダイムシフト）
初めて知った。テストのある世界ってこんなに素晴らしかったんだ

キッカケ
リファクタリングの方法を確立する（自分なりに）
最新のテスト手法を学ぶ
状態
自分なりのルールが芽生える
今までのテストを書き直す
テストの量（費用対効果）の感覚が芽生えてくる
テストなしでは生きられない

JUnit実践入門体系的に学ぶユニットテストの技法
渡辺修司著

完成期
すいません、本当のＴＤＤは、良く分かってません（暴露）

キッカケ
まだ、訪れていない・・・・
状態（聞きかじり）
ＴＤＤのサイクル
リズム・スピード
Ver管理・テスト・継続的インテグレーション

和田卓人の“テスト駆動開発”講座 2007/10~12
http://gihyo.jp/dev/serial/01/tdd

３．BlacｋJumboDogの
C#からJavaへの移植
昨年夏にＪａｖａ入門のムック本を買ってから・・・・


進捗状況
TCP/UDP及びテキスト/バイナリの全部を一応終わり、一段落しました

モジュール進捗状況

BJD.EXE（本体） 70% 70%

FTPサーバ 100% 100%
DNSサーバ 90% 90%
SMTPサーバ 0%
POPサーバ 0%
TFTPサーバ 0%
Webサーバ 0%
Proxyサーバ 0%
DHCPサーバ 0%

見た目は似てるが、そう甘く無かった
私が感じた主な障壁

 Unsigned・goto・Linq・varが無い
 リトルインディアンの問題
 refが無い(１つの戻り値しか許さない) パラメータのクラス化
 例外の扱いが違う（チェック例外/実行時例外）
 unsafeのポインタが使用でいない
 パディング１の構造体が使用できない
 formatの書式が異なる（自動変換は行われない）
 ==による文字列評価は、そくバグ


.NETのクラスライブラリ風を作成
とりあえずコンパイルを早く通すために・・・・・

プラグインにコーディング規約を教わる
とりあえずデフォルトのcheckstyleの言いなりになる


バグもある程度は教えてくれる
findbugなかなか・・・・


移植の手順（１）
依存関係の少ない、基本的クラスは既にテストが存在した

既にテストがある（基本的クラス）

テストだけを移植

本体を移植


移植の手順（２）
下位クラスは依存関係がハンパなく、ブラックボックス的テストしか存在しない

テストがないクラス

再設計（依存排除・再配置）

テスト作成

本体実装


Java入門のためのユニットテスト
テストがあれば、間違っていても気にしない

 とりあえずガリガリ書いてみる
 勉強を進めるうちに色々間違いに気づく
 テストを頼りにリファクタリンで修正する
 全面的な構造変換も躊躇なくできる
 テストが無いコードは設計が悪い（主に依存関係）


試行錯誤で得た自分なりのルールや手法



（１）メソッドは日本語
やってみるとあまりにも分かりやすいのでハマりました


メソッドは日本語（１）
結構長い間、抵抗があって躊躇っていたが・・・・

Eclipse+JUnit

メソッドは日本語（２）
やってみるとあまりにも分かりやすいのでハマりました

ReSharper+NUnit

メソッドは日本語（３）
FTPサーバのテストコード何のテストが有るか何となく分からないですか・・・

Eclipse+JUnit

メソッドは日本語（４）
DNSサーバのテストコード、これ英語で表現できない・・・・

Eclipse+JUnit


（２）テストコード定型化
基本（パラメータ）型・例外型・応用型
リファクタリングで整備し、テストコードのカオスから脱出する


基本型
変数名を統一することが重要、テスト対象はSystemUnderTest

@Test
public void funcで初期化した数値が返る() throws Exception {
//setUp
MyClass sut = new MyClass(123);
int expected = 123;
//exercise
int actual = sut.func();
//verify
assertThat(actual, is(expected));
//TearDown
} Java(Junit)

基本型
定型コメントで意図を明確にし、パターン外の特異事項のみコメントする

[Test]
public void funcで初期化した数値が返る (){
//setUp
var sut = new MyClass(123);
var expected = 123;
//exercise
var actual = sut.Func();
//verify
Assert.That(actual, Is.EqualTo(expected));
//TearDown
} C#(NUnit)

失敗時の表示も定型化される
いつも同じパターンの方が把握しやすい

C#(NUnit)

失敗時の表示も定型化される
いつも同じパターンの方が把握しやすい

Java(JUnit)

テストを読むのがつらくなる
基本型が無いと、毎回詳しく読まなければならなくなる

×
[Test]
public void Test1(){
var num = 123;
Assert.That(new MyClass(num).Func(), Is.EqualTo(num));
}

[Test]
var num = 123;
var myClass = new MyClass(num);
Assert.Equals(myClass.Func(), num);
}

DRY原則は適用しない
あくまで基本型にこだわる

×
[Test]
var num = 123;
Confirm(new MyClass(num), num);
}
[Test]
public void Test2() {
Confirm(new MyClass(567), 567);
}
private void Confirm(MyClass myClass, int num){
Assert.Equals(num,myClass.Func());
}

DRY原則は定型以外に適用する

〇
[Test]
//setUp
initialize();
var sut = new MyClass(CreateParamater(1,true,”TEST”));
var expected = 123;
//exercise
//verify
} copyright© 2011/03.. by SAPPOROWORKS

１つのメソッドで１つのテストが原則（１）
いろいろ試験したい気持ちは分かるが・・・・

×
[Test]
public void myClassの動作確認(){
Assert.That(sut.Func(), Is.EqualTo(123));

sut.Add(1);

sut.Add(2);
}

１つのメソッドで１つのテストが原則（２）
基本型重視の姿勢は、後々幸せを運ぶ

〇
[Test]
public void Addで保持する数字に追加される() {
//setUp
var expected = 100;
//exercise
sut.Add(100);
//verify
}
※このテストはAdd()のテストである

１つのメソッドでテスト対象は１つ
いろいろ試験したい気持ちは分かるが・・・・

×
[Test]
public void myClassの動作確認(){
var myClass1 = new MyClass(123);
Assert.That(myClass1 .Func(), Is.EqualTo(123));


}

基本型（例外の扱い）
チェック例外に対処しないとコンパイルが通らない

Java(Junit)

ちゃんとtry-catchすると複雑になる

×

Java(Junit)

ルール無用でExceptionをthrowしておく

〇

どうせ例外発生はテスト失敗だから・・・
Java(Junit)

.NETの場合、チェック例外は無いので華麗に無視しておく

〇
どうせ例外発生はテスト失敗だから・・・
C#(NUnit)

例外型
expected属性を使用する（JUnit）

〇

Java(JUnit)

例外型
ExpectedException属性を使用する（NUnit）

〇

C#(NUnit)

基本型（パラメータ）
基本型と同じ、便利で多用される

C#(NUnit)

基本型（パラメータ）
基本型と同じ、便利で多用される

Java(JUnit)

応用型
状態を保持するクラスは、基本型では冗長になりすぎる場合がある


応用型
いくつも確認したい事項がある時


応用型
カオス生成装置になりかねない

※基本型では、あまりに冗長になる場合のみ
※ちょっと油断すると・・・・応用ばかりになってしまう


定型化
いつみても見通しの良いテストコードを手に入れたい

 リファクタリングしながら、可能な限り、「基本（パラメータ）」
及び「例外」の２つの型を追及
 整理して、重複したテストは削除する
 テストコードはクラスのドキュメント（使用方法）となる
 仕様漏れの確認になる
 テストの見直しが嫌にならない



（３）クライアント・サーバ
初期化・終了処理・共通メソッドによるＦＴＰサーバのテスト


BeforeClassでサーバを起動
クラスの初期化

AfterClassでサーバ停止
クラスの終了処理


Beforeでクライアント起動
メソッドの初期化処理


Afterでクライアント停止
メソッドの終了処理


共通メソッドでログイン処理
このメソッドを使用して、ログイン後のテストを行う


クライアントを使用したサーバテスト


（４）バイナリデータのテスト
DNSのパケット解析クラスを実パケットでテストする


実パケットの採取
パケットの内容（解析結果）は、ここで確認できる


バイナリデータの取得
HexStreamでUDPのデータ部（DNSパケット）をコピーする

文字列でテストクラスに取り込む
ペーストでStringに格納する

Stringをbyte[]に変換
共通メソッドでbyte[]に変換する

パケット解析クラスのテスト
パケットモニタと同じ結果が得られるかテストする


（５）ガバレッジの利用
カバー率は問題ではない、レポートを有効に利用する


例外テストを作成
Aレコードに：：１を飲み込ませると例外が発生する


テストは失敗してしまう
ガバレッジを見てみると、予想外の動作をしているのが分かる


実装を修正してテストを成功させる
結果的には仕様論理バグ


TDDのはずなのに・・・
テストが無いのに勢いで実装している？

ガバレッジ１００％・・・
いつまでたっても終わらなくなる

 めざせ１００％？
ガバレッジで全部を緑にしようなんて考えると、大変な時間
を費やすことになる・・・・
（ツールの仕様上、１００％にはならない）

 ちなみに・・・・
実装側の例外処理を減らしても（品質は低下）、ガバレッジ
は上がる



（６）レッドとブルー
レッドとブルーの状態を大事にする


テストが最初に赤くなること
テストコードも単なるプログラム

これ重要！
ＴＤＤでは、１つのサイクルに
入っている

 テストコードも単なるプログラムなので、当然バグる
 テストしているつもりでも、テストになっていない
 最初にちゃんと赤くしてテストの正当性を確かめる

バグ修正の手順
問題発生時にブルーであれば、「仕様バグ」若しくは、「テスト漏れ」

問題発生

テスト作成

修正

※ちゃんとレッドにしてからバグ修正する


（７）その他
 プライベートメソッドは、リフレクションでアクセスできる
 Waitは、コンソールに***などを表示
 遅いテストをまとめて別メニューにする
 環境の違いなどでエラーの出たテストは、そのテストを追加する


５．テストについて説明してみる
よくある疑問への回答


進捗率（工数）について
現在の進捗率は？って聞かれたら・・・・

 以前は、一通り動いたらOKとしてきた
 テストを書くようになってからは、テストが必要な場合、そのテスト
を全部書き終わるOKと言えなくなった
 メンテナンス・仕様変更への対応は非常に楽になった
 何時の間にか、テストを含めた進捗率が正確なものだと感じるよ
うになった
 技術的負債を計上できるようになった


テストを書くと仕事が増える？
作業が少ないのは、技術的負債を多く抱えるという事

バグフィックステスト有のモデル

仕様変更

コーディング

早くできるのではなく、技術的負
債をどれだけ残すかという事テスト無のモデル

長期・大規模になると技術的負債の割合が大きい

短期間・小規模長期間・大規模
バグフィックス

仕様変更バグフィックス

コーディング仕様変更

コーディング


費用対効果が重要

 テストを書くと、開発時の工数は間違いなく上がるが、バグ発生
率は減り、テスト・デバッグを含めたトータルの工数は削減されて
いるかも知れない
 特に「規模の大きな」又は「長期」なプロジェクトでは、顕著かも知
れない
 「変更に強い」というあたりが絶対価値だと思われるが、それが必
要ないというのであれば工数増加だけが問題になるのは否定で
きない


テスト駆動は、新たなパラダイム
今までの認識や価値観などが革命的・劇的に変化する

Macro
(Lotus123) C
(MSC/Turbo C) C++/C#/Java
(オブジェクト指向)

F#
(関数型)
テストファースト
(NUnit/JUnit)

理解度による見えているものが違う
自分にも見えていないものがまだあるはず・・・

どうやって書けばいいか分からない
新しい言語を始めたぐらいの気持ちで取り組むしかない

 初めてプログラムを書いているのと同じ
 小さなプログラムは書けても大きなプログラムは書けない
 一応書けるが、きれいに書けない
 後で読めない

とにかく練習するしかない
実は設計手法なのでそう簡単には習得できない


どうやって書けばいいか分からない
一応とっかかりを・・・・・例示してみる

多態性の実装
・まず、最初にgetInt() setInt()を普通に実装する
・getShort setShort getLong setLongはTDDで作成する

２．クラスのみミニプログラム
・全体のコードを忘れて、１クラスのみ生成して実行する１
つのプログラムを作成する
・「基本型」をとりあえず書いてみる


有効性の実感
２期から３期へのキッカケ

TDDが優れた手法だと気付くタイミング・理由は人そ
れぞれだと思います

 実装しようとしているモジュールの設計が洗練されていく感
覚を味わったとき
 カオスとなったレガシーコードが少しずつ甦ってきたとき
 回帰テスト前に、思わぬ不具合を早期に検出できたとき
 大胆なリファクタリングを躊躇無くできたとき
など・・・・

あなたにとってテストは必要ですか
１つでも有効性を感じれれば、やってみる価値があると思います

 フィードバックと安心  具体的なテストデータ
 リファクタリング  習得可能なスキル
 インターフェイスへの意識  環境へ非依存
 シンプル設計  たくさんコードを書ける
 メンテナンスされたドキュメント  開発が楽しくなる

やさしいデスマーチ「TDDを学ぶべき10の理由」より
http://d.hatena.ne.jp/shuji_w6e/20111204/1323011355


ターゲットが複数にわたるプロジェクト
テストによる新たな手法か・・・・

 複数プラットフォーム用のコードは限界がある
 実装漏れ
 仕様変更漏れ
 バグフィックス漏れ

テストパターンを保守する
テストが簡潔な仕様書になっている事が前提


（最後に）品質より価値の追求
変更への強さが最も大事かもしれない

 バグが100%と取り除いて、仕様通りのプログラムを仕上
げても、それが顧客の価値に直結するとは限らない
 もともと、仕様決定は一時的な最適解であって、状況の
変化で変わってくる
 これに追従してこそ、真の価値が生まれる
 テストコードに向き合う際も、カバレッジを上げるとか、
条件網羅を上げるより、変更への強さを追及するべき
なのかも知れない


ご清聴ありがとうございました

@furuya02


C# から java へのプログラム移植で体験したtddの効果は？

More Related Content

C# から java へのプログラム移植で体験したtddの効果は？