テスト駆動開発入門

Size: px

Start display at page:

Download "テスト駆動開発入門"

ありさみのしま
5 years ago
Views:

1 テスト駆動開発入門ハンズオン講座 goyoki

2 概要イントロダクションハンズオン課題 1 TDDの概要定義 / 手順 / 利益などハンズオン課題 2 ソフトウェアテストとしてのTDD

3 後編について以下は後編で扱う予定です TDDが抱える課題レガシーコード上でのTDD テストコードの改善 TDDで確保したテストコードの活用 TDDの諸目的

4 イントロダクション

5 テスト駆動開発 (TDD) テストファーストプログラミングの 1 手法アサートファーストプログラミング技法 Kent Beckが具体的な方法論としてまとめる

6 TDD のステップ 1. 最初にテストを書いて実行 (RED) 2. テストをパスするまでコードを実装 (GREEN) 3. コードをきれいにする (REFACTOR) RED GREEN これを繰り返しインクリメンタルに実装を進める Refactor

7 コードの 4 象限と TDD のサイクルきれい Red Refactor 汚い Green うごかないうごく

8 ハンズオン課題 1

9 実装仕様うるう年判定関数 ( グレゴリオ暦 ) 西暦年が4で割り切れる年は閏年ただし西暦年が100で割り切れる年は平年ただし西暦年が400で割り切れる年は閏年

10 TDD の概要

11 TDD の定義テスト駆動開発入門 Kent Beck バイブル的存在方法論としての厳密な定義を強制しない TDD は XP のように絶対的ではないテスト駆動開発入門有力な原則やアドバイスで方法論を構築

12 TDD の原則 Robert C Martin の 3 原則失敗するユニットテストを成功させるためにしかプロダクトコードを書いてはならない失敗させるためにしかユニットテストを書いてはならないコンパイルエラーは失敗に数えるユニットテストを 1 つだけ成功させる以上にプロダクトコードを書いてはならない

13 TDD のテストの原則完全な自動テストであること自己完結できるテストであること初期設定実行検証がセットとなっている繰り返し可能なテストであること何度実行しても結果は同じ独立して実行できるテストであること一緒 / 個別に実行しても結果は同じ順不同でも結果は同じ十分に細粒度であること作業の最小単位ごとにテストを書く

14 TDD の手順 (Red Green Refactor のサイクル )

15 TDD の流れ RED 失敗するテストを書く GREEN テストをパスするまでコードを書く Refactor テストを使ってリファクタリングする

16 Red のステップテストを書く失敗するテストを継ぎ足す小さなテストを書くここで書いたテストが実装作業単位になる

17 Green のステップテストをパスするコードを書く Red のステップで失敗しているテストを通すまでコードを書くテストが失敗状態のまま他の作業に移らない

18 Refactor のステップ Green で追加変更したコードをきれいにするテストがパスした状態を維持する既存のテストで可能なリファクタリングを行う新規実装の場合は Red のステップに移る Refactorのために新たにテストを追加してもよい実行するほどでもないなら飛ばしてもよい

19 TDD の利益

20 TDD の利益 1. すばやく継続的なフィードバック 2. 作業の細分化局所化 3. 単体テスト容易性の向上

21 すばやく継続的なフィードバック単体テスト環境の整備実装未達の即時検出デグレードの即時検出 TDD 上での実装作業は単体テストでリアルタイムに検証される TDD 上では自動化された回帰テスト環境を容易に構築できる

22 作業の細分化局所化 Defect Localization やっていることやるべきことを絞り込む不完全な作業を 1 つに絞り込むテスト = 実装仕様としてやるべきことを具体化できる TDD では Green 状態をこまめに確保テスト失敗原因直近の作業を実現

23 単体テスト容易性の向上リファクタリング容易性の向上単体テストのすぐれた網羅性 TDD では製品コードが単体テストに対して最適化されるリファクタリングや Cover&Modify が容易になりコードの品質 ( 移植性等 ) が向上する

24 TDD でのテクニック (Red Green Refactor のサイクルの中でのテクニック )

25 テスト駆動開発入門における 1. Fail It 2. Fake It 基本パターン 3. Triangulate( 三角測量 ) 1~3 を十分に積み重ねた後 4. Obvious Implementation( 明白な実装 )

26 1. Fail It Pubic void test 引数を倍にして返す () { assertequals(6, 引数を倍にして返す (3)); } 製品コード Pubic int 引数を倍にして返す (int input) { } スケルトンあるいは未実装

27 2. Fake It Pubic void test 引数を倍にして返す () { assertequals(6, 引数を倍にして返す (3)); } 製品コード Pubic int 引数を倍にして返す (int input) { return 6; }

28 3. Triangulate( 三角測量 ) Pubic void test 引数を倍にして返す () { assertequals(6, 引数を倍にして返す (3)); assertequals(10, 引数を倍にして返す (5)); } 製品コード Pubic int 引数を倍にして返す (int input) { return 6; }

29 テストコード 4. Obvious Implementation ( 明白な実装 Pubic void test 引数を倍にして返す () { assertequals(6, 引数を倍にして返す (3)); assertequals(10, 引数を倍にして返す (5)); } 製品コード Pubic int 引数を倍にして返す (int input) { return input * 2; }

30 ステップの調整ステップ粒度は不安や慎重度に応じて調整慎重な場合 Fail It(Compile Error) Fait It(Red) Fake It Triangulate Obvious Implementation 平易な場合 Fail It Obvious Implementation

31 注意 Triangulate の扱いは意見が分かれる長所 : 作業をより細かいステップに分けられる Fake Itではビルド実行可能かどうか検証できるインターフェースが妥当か検証するステップになる短所 : 重複するテストが生まれる Fragile Test の原因となる作業のステップの大小に応じて調整する

32 TDD でのテストコードの整理

33 テストコードの整理テストコードを整理する場面製品コードの変更に追従するためにコードの変更で冗長になったテストを最適化するインターフェースの変更に追従するテストコードの品質を向上させるためにテスト設計を損なわないようにテスト実装を整理する TDDの中で生まれたテストの冗長性を整理する

34 テストコードの整理 TDD の一部として扱われないしかし放置すると TDD を非効率なものにする製品コードのリファクタリング容易性や拡張性を損なう (Fragile Test 等 ) テストコードがミスを見逃すようになる (Buggy Test 等 ) TDD の作業量を無用に増大させる (Assertion Roulette,Slow Test 等 ) テストコードの保守性を低下させる (Obscure Test 等 ) 詳細は後編 TDD の効率を維持するために不可避なステップ

35 整理のタイミング TDD のサイクル上のタイミング Red Green Refactor テストコード整理リファクタリングに合わせて最適化 (Red Green Refactor) を繰り返すテストコード整理蓄積したテストコードをまとめ上げるその他タイミング特定のイベント前コミット前 /CI などへの組み込み直前 / 派生先への流用前等

36 整理の目標 TDD のテストの原則を目指す完全な自動テストであること / 自己完結できるテストであること / 繰り返し可能なテストであること / 独立して実行できるテストであること十分に細粒度であること単体テストとしての妥当性を目指す簡単に実行できるべきテストは品質向上を手助けしてくれるべきテストはテスト対象の理解を手助けしてくれるべきテストはリスクを削減してくれるべきテストは簡単に実行できるべきテストは簡単に変更保守できるようにするべきシステムの機能拡張時でもテストの変更は最小限になるようにすべき

37 テストコードの整理での注意点アドバイス慎重に行うテスト設計の等価性を保証する技法は揃っていない状態一時的であっても Lost Test は避けるアプローチは基本的に Parallel Change テストの削除は代替が十分に揃ってから製品コードを工夫するテストコードの保守性を観点に製品コードを組む言語ツールの力を借りる IDE のリファクタリング機能といった低リスクな機能を積極活用

38 テストコード整理の例 Custom Assertion による置換まとまった Assertion のセットを一つの Assertion にまとめる Assertion のセットの重複記述を解消する注意利点欠点共にある CUnit といった行番号情報が重要なフレームワークではプリプロセッサでまとめたほうが良い

39 Custom Assertion Pubic void test3() {. assertequals(bar.a(), foo.a()); assertequals(bar.b(), foo.b()); assertequals(bar.c(), foo.c()); Pubic void test2() {. assertequals(bar.a(), foo.a()); assertequals(bar.b(), foo.b()); assertequals(bar.c(), foo.c()); Pubic void test1() {. assertequals(bar.a(), foo.a()); assertequals(bar.b(), foo.b()); assertequals(bar.c(), foo.c()); }

40 Custom Assertion Pubic void test3() {. assertequals(bar.a(), foo.a()); assertequals(bar.b(), foo.b()); assertequals(bar.c(), foo.c()); Pubic void test2() {. assertequals(bar.a(), foo.a()); assertequals(bar.b(), foo.b()); assertequals(bar.c(), foo.c()); Pubic void test1() {. assertequals(bar.a(), foo.a()); assertequals(bar.b(), foo.b()); assertequals(bar.c(), foo.c()); } static void asserthoge(fuga exp, fuga act) { assertequals(exp.a(), act.a()); assertequals(exp.b(), act.b()); assertequals(exp.c(), act.c()); }

41 Custom Assertion Pubic void test3() {. asserthoge(bar, foo); Pubic void test2() {. asserthoge(bar, foo); Pubic void test1() {. asserthoge(bar, foo); } static void asserthoge(fuga exp, fuga act) { assertequals(exp.a(), act.a()); assertequals(exp.b(), act.b()); assertequals(exp.c(), act.c()); }

42 TDD を支えるテスティングフレームワーク

43 TDD を支えるテスティングフレームワーク自動化された単体テストをサポートするフレームワークが多用 s される xunit フレームワークが一般的 TDD で用いられる他のフレームワークでも xunit と同等の機能を持つことが多い

44 xunit Kent Beck が Smalltalk 用に作成したテスティングフレームワークが元祖その設計思想に従った単体テスティングフレームワークの総称 JUnit Sunit Nunit cppunit など

45 xunit 階層構造カテゴリによりテストを構造化 Test Assert : Test Method : Test Suite Four-Phase Test でテストの独立性や保守性を向上 Setup Exercise Verify Teardown 開発言語の設計構造を活用しテストの保守性を向上 JUnit:Test Suite の定義に Class カテゴリの定義にアノテーション等を活用

46 xunit の構造 Sketch Static Test Structure 参照

47 xunit の構造 : 基本用語解説 SUT(System Under Test) テスト対象 Fixture テスト実行前に SUT に対して行う事前設定 Test Runer テストを実行 Suite を抜き出してテストを実行するプロセス Test Double テスト実行時に SUT が依存するコードやコンポートンとの代替となるもの

48 ハンズオン課題 2

49 課題本リストを管理する Class 書名と価格を格納できる格納順でもっとも古い本を削除できる格納順の番号で本を検索できる書名から価格を検索できる

50 ソフトウェアテスト手法としての TDD

51 TDD の主な対象工程異論もある

52 TDDのテストと工程検査の単体テスト設計は何が違うのか? 傾向としての違い : テストファーストで作られる製品コード実装と連携して実装される実装上の意図を元に設計される継続的でインクリメンタルに設計される

53 TDD はどのようなテスト設計技法なのか? TDD では特定のテスト設計技法を強制しない単体テストの実装タイミングについて規定する一般的な単体テスト設計技法と両立可能 Ex) 全体的なテスト設計を実施 1 つ 1 つ切り出して Red>Green>Refactor のサイクルを回すただ TDD との相性として技法の適不適はある

54 TDD と従来の単体テスト設計は一致させられるか? 一致は可能しかし一般的に非効率実装作業のサポートという観点が抜け落ちたテスト設計は TDD のメリットを削ぐ実装作業のサポートという観点で設計されたテストはテスト設計として冗長性や抜けを持つことが多い

55 TDD と従来の単体テスト設計は一致させられるか? 一致でなく共存による相乗効果を目指す TDD では整合性のある単体テストを内包するように実装を進める工程保証ステップでは TDD で確保されたテスト容易性テストコードを活用する

56 共存プロセス目的の単体テストを内包するように TDD を進める特定の単体テスト TDD のテストコード

57 共存プロセス Outside-In の TDD 上位設計をブレークダウンしていく

58 共存プロセス詳細設計と TDD で反復フローを構成設計テストの方向性を提示設計改善をフィードバック実装中は Fix しない

59 まとめ TDD とは / では Red Green Refactor のサイクルでコードとテストを蓄積していく自動化された単体テストで継続的かつ即時のフィードバックを実装作業に返す単体テスト容易性と単体テストコードを確保するソフトウェアテストとして協調できる

テスト駆動開発入門ネクストステップ

テスト駆動開発入門ネクストステップテスト駆動開発入門ネクストステップ井芹洋輝謝辞主催の今給黎さん和田さん会場提供スタッフの方々参加者の皆さま深くお礼申しあげます自己紹介井芹洋輝 (@goyoki/id:goyoki) 組み込みエンジニア WACATE 実行委員 /TDD 研究会講演 / 執筆 : XP 祭り関西ユニットテストの保守性を作りこむ Androidテスト祭りテストの活用による開発効率化並カン