テストの自動化は、無敵の用心棒のように思える
Posted: 2012年11月03日テストの自動化は、様々な方法が存在します。
- ユニットテストの導入
- マウスとキーボード入力の自動化
ユニットテスト
ユニットテストは、テストプログラムを作成し対象のプログラムをテストを行います。
主にTDD(テスト駆動開発)で使います。
プログラム設計ができた場合その対象の関数が
どのような動作を行うかすでにわかっているはずです。
つまり、ユニットテストでそれを記述するプログラムを作成する。
その後実際のプログラムを作成し
設計通りであるか確認をする手法です。
TDD以外でユニットテストを活用
目標は、TDDを行いたいですが
最近は、そこまでしっかりとした設計を行うことがないため(大規模開発の場合はありえない)
なかなか導入はできない。
そのため開発は以下の順で行なっています。
- 実装
- ユニットテストの作成
- リファクタリング
- 結合テスト
この順番で行うことで
リファクタリング、結合テストの障害対応時に誤った修正を加えていないか
が確認できるため安心して納品が可能です。
※ユニットテストは、関数の結果がわからない場合は、
何が正解かが不明なため実装時にそこは考慮する必要があります。
ユニットテストでは開発できない問題また、ユニットテストを行ったから問題ないかと言ったらそうではなく
以下の点は、テストができないため
そこは、別の方法てテストが必要になります。
- 画面の描画
- 画面操作
- 性能チェック
- 排他制御(デッドロック)
マウスとキーボード入力の自動化
ユニットテストの問題を一部解決できます。
- 画面操作※
- 性能チェック
- 排他制御(デッドロック)
※一部の操作のみ
ユニットテストと一緒に導入することで
様々なテストを網羅することが可能です。
これは、マウス操作などを自動で行うことで
- タイミングによるデッドロックの確認
- 画面操作によるメモリーリークなどの性能チェック
これらの確認が可能になります。
こちらは、TDDには含まれていないと思いますが
画面は、設計時に決定しても仕様変更などがあり
変わる場合があるため、TDDで導入してもメンテナンスが大変だと思います。
(マウスの座標を記憶させるため)
まとめ
今回上げた、ユニットテストやマウスとキーボード入力の自動化を
行なっていたとしてもバグは発生します。
しかし、大幅に削減できるし
テストが自動化されることでSEの安心感は得られます。
テスト作成に時間がかかるという欠点はありますが
見積もりでその分上乗せすることで解決できると思っています。
相手もテスト自動化は安心できる材料であると思っています。
自動テストは、無敵ではないにしろ
心強い用心棒であることは間違いないと思います。
コメント