Contenu connexe
Similaire à Unit testで定時帰宅！
Similaire à Unit testで定時帰宅！ (20)
Plus de Funato Takashi (7)
Unit testで定時帰宅！
- 4. そもそもテストとは
• ソフトウェアテスト
> コンピュータのプログラムを実行し、正し
く動作するかどうか確認する作業
> プログラム中の欠陥（バグ）をできる限り
多く発見することを目標として行われる
> ソフトウェアテストに成功するとは、欠陥
を発見することである。ソフトウェアテス
Via:Wikipedia
トでは、欠陥が存在することを示すことは
- 5. ユニットテストとは
• 単体テスト（Unit Testing）
> 単体テスト、あるいはユニットテストと
は、メソッドなどの小さな単位で行うテス
トのことである。単体テストは、ホワイト
ボックステストを利用して行われる場合が
多い。 プログラムは
機能 機能 複数の機能（モジュール）が
機能 機能
> 品質を上げることはできるが、要求を満た
機能 機能
組み合わさって成り立ってい
る。
機能単位でユニットテストを
しているかはわからない 作る
- 6. ユニットテストとは
• アジャイルな開発手法で必須
> 仕様通りに動くか確認
• ユニットテストが仕様書にもなる
> ドキュメントはメンテナンスがされなくな
る アジャイルフトウェア開発
> 動いているものが正解
迅速かつ適応的にソフトウェア開発を
行う軽量な開発手法群の総称 。
代表的な手法にXPやスクラムなどがあ
る。
- 9. なぜユニットテストを書く
の？
• 問題を小さなうちに摘み取る
• 問題の発生を初期の段階で防ぐ
• 仕様の確認
あなたの書い
• 使い方がわかる たコードは本
当に正しいで
すか？
- 10. 問題を小さなうちに摘み取る
• 問題を小さなうちに摘み取る
> ハインリッヒの法則
• 1件の重大災害の裏には、29件のかすり傷程度
の軽災害があり、さらにその裏にはケガはな
いものの300件のヒヤリとした体験が存在して
1件の重大な事故・災害
いる ２９件の軽微な事故・災
> 問題は後になるほど重症化する害
３００件のヒヤリ・ハット
• 問題が広範囲にわたる
- 11. 問題の発生を初期の段階で防
ぐ
• 問題の発生を初期の段階で防ぐ
リリースする前の
> 動かない 問題発覚と
リリース後の問題発覚
• ユニットテストで動かしてみる
コストが高いのは？
> 間違った動作
• 検証することで確認する
> 性能
• 実際に動かすことで確認できる
- 12. 仕様の確認
• 仕様の確認
> アジャイルな開発では実装のよりどころと
するドキュメントが少ない。実装を説明す
るよりもテストコードを見たほうが早い
> 机上の設計書よりも動くコード
- 13. 使い方がわかる
• 使い方
> ユニットテスト見れば、そのクラスの使い
方、何をしているかわかる
> 学習テスト 学習したいライブラリなどをユニット
テスト書いて実行して使い方や内容を
確認します。書いて使って覚える！
- 17. 規約を作ろう ・場当たり的なテストはしな
い。
• 書き方の規約 ・環境に依存したテストは注
意
> テストメソッドの規約 ・テストを書けないものもあ
る
• メソッド名はtest~から始まる
> テストクラス名の規約
• テスト対象のクラス名＋Test
> テストケースはシンプルに
• 複雑なテストケースになる場合は設計を見直す
- 18. ツールを使おう
• ツール
> Junitはあたりまえ
• Junit4を使いましょう。アノテーション便利
> Seasar周りのテストツール
> Eclipseプラグイン
• Seasar使ってるならS2Junit4 Pluginを入れよう
– http://s2junit4plugin.sandbox.seasar.org/
– ただしQuickJunitと相性悪し
> Maven2
• レポート作ってくれる
- 20. ツールを使おう
• S2JUnit4
> できること
• 自動フィールドバインディング
• DBアクセス
– DataAccessor
• MockIntercept
– インターフェースなしでメソッドの返り値を自由自
在
• テストデータを自動で用意
http://s2container.seasar.org/2.4/ja/S2JUnit4.html
• 検証用データとDBの比較
- 21. ツールを使おう
• S2JUnit4 Plugin for Eclipse
> もともとはQuickJunitの派生
> Ctrｌ+9でテストコードと実装コードを行
き来
> Ctrl+0でテスト実行、Ctrl+Shift+0でデバッグ
> Ctrl+Shift+9 でテスト用Diconファイル編
http://s2junit4plugin.sandbox.seasar.org/
集
- 23. ツールを使おう
• Hudson
> 「継続的インテグレーション」
（Continuous Integration ）
• ファウラーたんによって広められた
• 別々に開発された部品を持ち寄ってお互いの
動作を検証する「統合テスト」を早い段階か
ら恒常的に行うこと
• CIは単に統合テストだけではなく，広くビル
- 24. S2Junit4を掘り下げてみる
• 自動フィールドバインディング
> ルール
• バインディング対象のフィールドは非static、非final、
非プリミティブ型かつnull
• フィールドの変数定義がインターフェース型でそのイン
タフェースをもつコンポーネントがコンテナに存在する
場合、そのコンポーネントがフィールドにセットされる
• バインディングは、テストメソッド実行の直前に行われ
RunWithで
る（ただしTestContextインタフェースは例外的に
Seasar2.classを
before()メソッド実行前にバインディングされる）。テ
忘れずに
ストメソッドの実行が終了するとバインディングされた
- 27. S2Junit4を掘り下げてみる
• MockIntercept
> モックにしたいクラスにAOPで
<component class="examples.aop.Hello">
<aspect>
<component class="org.seasar.framework.aop.interceptors.MockInterceptor">
<initMethod name="setReturnValue">
このDiconファイ <arg>"greeting"</arg> メソッド名
<arg>"Hello"</arg>
ルも </initMethod> 返り値名
S2Junit4Plugin <initMethod name="setReturnValue">
OGNL式で書く
<arg>"echo"</arg>
で作る
<arg>"Hoge"</arg>
</initMethod>
</component>
</aspect>
</component>
- 30. ユニットテストをしっかりや
ると
• 仕様変更に強くなる
> テストがあるから変更にも強い！
• ソースコードの保守がしやすくなる
> メンテナンスコスト低減
• 品質が上がる
> 最初の時点でバグつぶし
> 要求に対する適合度
• 設計がシンプルになる
> テストがシンプルなら設計もシンプル
Notes de l'éditeur
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
