Unit Test
WHO?
• 松村 勇輝
• Twitter. @Yuki_312
• Yukiの枝折. http://yuki312.blogspot.jp/
• Android Developer
CONTENTS
• ソフトウェアの変更
• ユニットテスト
• テスタビリティ
• 依存性の排除
• Mockito
ソフトウェアの変更
ソフトウェアの変更
• ソフトウェアを育てるには変更作業が必要
ソフトウェアの変更
• ソフトウェアを育てるには変更作業が必要
• 新しい価値の追加
ソフトウェアの変更
• ソフトウェアを育てるには変更作業が必要
• 新しい価値の追加
• バグの修正
ソフトウェアの変更
• ソフトウェアを育てるには変更作業が必要
• 新しい価値の追加
• バグの修正
• コードの改善
ソフトウェア開発の課題
プログラムを壊さずに変更しなければならない
プログラムが壊れる原因はいつも“開発者の変更”
恐怖
恐怖
• 複雑で, 理解し難く, 調べても確証を得られない
恐怖
• 複雑で, 理解し難く, 調べても確証を得られない
• “成功しますように”と祈りながらリリースする
恐怖
• 複雑で, 理解し難く, 調べても確証を得られない
• “成功しますように”と祈りながらリリースする
変更によるソフトウェア破壊の恐怖
悪影響・悪循環
悪影響・悪循環
• 変更することに対して消極的になる
悪影響・悪循環
• 変更することに対して消極的になる
• 動いている(ように見える)から触らない
悪影響・悪循環
• 変更することに対して消極的になる
• 動いている(ように見える)から触らない
• 暫定対処, 応急処置ばかりのツギハギコード
悪影響・悪循環
• 変更することに対して消極的になる
• 動いている(ように見える)から触らない
• 暫定対処, 応急処置ばかりのツギハギコード
• コードの臭いを放置する
悪影響・悪循環
• 変更することに対して消極的になる
• 動いている(ように見える)から触らない
• 暫定対処, 応急処置ばかりのツギハギコード
• コードの臭いを放置する
• リファクタリングしたくない
悪影響・悪循環
• 変更することに対して消極的になる
• 動いている(ように見える)から触らない
• 暫定対処, 応急処置ばかりのツギハギコード
• コードの臭いを放置する
• リファクタリングしたくない
技術的負債が増すばかりで改善されない
恐怖にどうやって立ち向かうのか
ユニットテスト
ユニットテスト
ユニットテスト
• システムに期待する“振る舞い”を記述するテスト
ユニットテスト
• システムに期待する“振る舞い”を記述するテスト
• プログラマ自身が書くDeveloper Testing
ユニットテスト
• システムに期待する“振る舞い”を記述するテスト
• プログラマ自身が書くDeveloper Testing
• ユニットテスト≠単体テスト
ユニットテスト
• システムに期待する“振る舞い”を記述するテスト
• プログラマ自身が書くDeveloper Testing
• ユニットテスト≠単体テスト
• 小さなパーツ(クラス相当)がテスト対象
ユニットテスト
• システムに期待する“振る舞い”を記述するテスト
• プログラマ自身が書くDeveloper Testing
• ユニットテスト≠単体テスト
• 小さなパーツ(クラス相当)がテスト対象
• 自動化されて頻繁な実行が可能
sample test code.
Product code
Test code
ユニットテスト
ユニットテスト
• 素直にテストコードが書けることは稀
ユニットテスト
• 素直にテストコードが書けることは稀
• 既存コードにポン載せできるほど甘くない
ユニットテスト
• 素直にテストコードが書けることは稀
• 既存コードにポン載せできるほど甘くない
• テストできるようにコードを変更する必要がある
horror code.
Product code
Test code
どうやってテストできるコードにするのか
考慮すべきはTestability
Testability
Testability
• Testabilityはソフトウェア品質特性の1つ
• 試験性, テスト容易性
• 拡張性や再利用性とは毛色が違う
Testability
• Testabilityはソフトウェア品質特性の1つ
• 試験性, テスト容易性
• 拡張性や再利用性とは毛色が違う
• Testabilityは意識しないと向上させるのが難しい
• テストのために設計・実装変更する必要がある
• 美的感覚に反する変更を必要とするケースがある
ユニットテストまとめ
• ソフトウェアの破壊を検知できる
• 素早いフィードバックが得られる
• リファクタリング効果がある
• 品質保証のツールではない
write testable code.
依存コンポーネント
@Test Target
Network
Database
依存コンポーネント
テストケース
• テスト対象が関連を持つ“依存コンポーネント”
テスト対象
依存コンポーネント
• テストの安定性や速度のリスクが増す
• 間接入出力の検証が困難
• テスト対象の依存性排除が課題
Database
間接入出力の検証
Target@Test
依存性の排除
Target
• 依存コンポーネントのテストダブルを用意
• テスト可能 + テストパフォーマンスUP
@Test Test Double
代替品で置き換える
testable code.
依存性の排除
• テストできない構造 – Singleton
• テストダブルが作りづらい
• テストできない実装
• 依存オブジェクトの排除ができない
• テストできない領域 – Library
• ライブラリクラスのリファクタリングができない
test double.
Test Double
• Test Stub
• Test Spy
• Mock Object
• Fake Object
• Dummy Object
Mockito
• Java向けモックライブラリ
• テスト対象の依存コンポーネントのダブルを生成
• 完全なモック
• 既存クラスの完全なモックを生成する
• 部分的なモック
• 既存クラスの部分的なモックを生成する
mock
mock
おわりに
• 祈ることをやめ, 恐怖に打ち勝つ対策を打とう
• ソフトウェアの破壊を手軽に検知できる仕組みが大切
• コードの改善に努めよう
• 依存性の排除にはMockitoが便利
• CIとの相性○
• Writable → Readable → Testable
よりテスタブルなソフトウェアを目指して,
DI, アーキテクチャにも取り組みましょう.
以上
ご清聴ありがとうございました

UnitTest