Rui software

テストの自動化は、様々な方法が存在します。

• ユニットテストの導入
• マウスとキーボード入力の自動化

ユニットテスト

ユニットテストは、テストプログラムを作成し対象のプログラムをテストを行います。
主にTDD（テスト駆動開発）で使います。
プログラム設計ができた場合その対象の関数が
どのような動作を行うかすでにわかっているはずです。
つまり、ユニットテストでそれを記述するプログラムを作成する。

その後実際のプログラムを作成し
設計通りであるか確認をする手法です。

TDD以外でユニットテストを活用

目標は、TDDを行いたいですが
最近は、そこまでしっかりとした設計を行うことがないため（大規模開発の場合はありえない）
なかなか導入はできない。
そのため開発は以下の順で行なっています。

1. 実装
2. ユニットテストの作成
3. リファクタリング
4. 結合テスト

この順番で行うことで
リファクタリング、結合テストの障害対応時に誤った修正を加えていないか
が確認できるため安心して納品が可能です。

※ユニットテストは、関数の結果がわからない場合は、
何が正解かが不明なため実装時にそこは考慮する必要があります。

ユニットテストでは開発できない問題また、ユニットテストを行ったから問題ないかと言ったらそうではなく

以下の点は、テストができないため
そこは、別の方法てテストが必要になります。

• 画面の描画
• 画面操作
• 性能チェック
• 排他制御（デッドロック）

マウスとキーボード入力の自動化

ユニットテストの問題を一部解決できます。

• 画面操作※
• 性能チェック
• 排他制御（デッドロック）

※一部の操作のみ

ユニットテストと一緒に導入することで
様々なテストを網羅することが可能です。
これは、マウス操作などを自動で行うことで

• タイミングによるデッドロックの確認
• 画面操作によるメモリーリークなどの性能チェック

これらの確認が可能になります。
こちらは、TDDには含まれていないと思いますが
画面は、設計時に決定しても仕様変更などがあり
変わる場合があるため、TDDで導入してもメンテナンスが大変だと思います。
(マウスの座標を記憶させるため)

まとめ

今回上げた、ユニットテストやマウスとキーボード入力の自動化を
行なっていたとしてもバグは発生します。
しかし、大幅に削減できるし
テストが自動化されることでSEの安心感は得られます。
テスト作成に時間がかかるという欠点はありますが
見積もりでその分上乗せすることで解決できると思っています。
相手もテスト自動化は安心できる材料であると思っています。

自動テストは、無敵ではないにしろ
心強い用心棒であることは間違いないと思います。