プログラミングのテストとバグ取り

• 作成日: 2021-12-17
• 更新日: 2023-12-24
• カテゴリ: プログラミング

私の好きなプログラミングのテスト方法

テストはソフトウェアの品質を改善する。
これに異論がある開発者もいると思うが、私は少なくともそう思っている。
テストがあるソフトウェアは品質が高く、テストがないソフトウェアの品質は未知数だ。

これはテストがそのソフトウェアのポテンシャルを明らかにするためだ。
テストを書き、ソフトウェアをテストすることでプログラムの動作を明らかにする。
テストがあればバグを発見できるので、バグを潰せば自然にソフトウェアの品質は上がる。

問題なのはGUIの場合だ。
GUIのテストはむずかしい。
そのため私もGUIのテストは省略することがある。
しかし、UIとは関係ないモジュールは当然ながらテストが必要になる。

テストはすばらしい。
テストはソフトウェアの開発を容易にすることができる。
テストで明らかになった動作に対して、問題を解決していくことでソフトウェアの開発を前進することができる。
テストの量はそのソフトウェアがどれだけテストで固められているかの指標になる。
当然ながらテストの量は多ければ多いほどいい。
多すぎてよくない、なんてことはない。
とにかく書きまくるのがいいが、規模によっては書きまくるのも疲れるだろう。

テストの種類

テストには種類がある。
一番基本的なテストが単体テストだ。
これは関数などのテストになる。

その次にこれも基本だが結合テストだ。
これは複数の機能を組み合わせたテストになる。

システムテストではシステム全体のテストを行う。

他にも色々なテストがあるが、私が許容範囲にしているのは上の3つのテストだ。
今回は単体テストの手法について書く。

単体テストの手法

単体テストの手法と言っても、手法なんて大したものではなくてごく一般的なものだ。
まず関数などに対して入力と期待する出力を書く。
テストを実行して関数の出力が期待した結果でなかったらアウトだ。修正する。

単体テストを先に書いて、テストを通る様に関数を実装するという手法もある。
これはテストファーストで、テスト駆動と呼ばれる。
私は実際の開発ではテスト駆動はあまり使わない。

ときおり先にテストを書くことはあるが、毎回テストを先に書くわけではない。
私は関数について試行錯誤することがあるので、試行錯誤のたびにテストを書き直していると時間がかかって仕方ないのである。

しかしテスト駆動で先にテストを書いておくと、結果的にはやく関数が仕上がることも多い。
設計がまとまっていたらテスト駆動を取り入れても良いと思う。

テストとバグ取り

バグがあるとしよう。
どうやってバグを取ればいいのか？

これにはまず、バグを再現する最小のテストを書く。
バグが再現するコードが大きい場合は、徐々にコードを削って行って最小のコードにする。

こうしておくと、バグが取れやすくなる。
バグが再現する最小のコードまで削ったら、あとはデバッガやprintfデバッグでデバッグする。
コードを削ってあるので、呼び出される関数も少なくて済む。
その結果デバッグもはかどる。

テストはバグを取るのに大いに役立つ。
というかテストを書く理由はバグを出さないようにするためなので、これは必然と言える。

もしテストをまったく書かない開発をしているとしたら、その開発者はそのうちバグに捕まってしまうかもしれない。
そのバグは開発者を離さずに何日も開発者を苦しめることになる。

バグを減らしたいならテストを書き、バグを退治したいならテストを書く。
テストは開発の道しるべといえる。

GUIは？

えらそうなことを言っているが、私もGUIのテストはあまりしない。
なのであまり大きな声では言えない。

GUIはインターフェースに関わる部分が大変だ。
このボタンを押してポップアップしたウィンドウのこのボタンを押したら、この結果が出る。
などというGUI絡みのテストを書くのは大変なのだ。

さいきんのWebではVueやReactもJestなどのテストライブラリを使えば、そういったGUIのテストができる。
私もたくさんそういったテストを書いたが、どうもGUIのテストはしっくりこない。
なぜだろう。
CUIに慣れ過ぎているせいだろうか。

おわりに

バグ取りとテストは非常に近い関係にある。
もしバグがなかなか取れない状態が続いていたら、一番の近道はテストを書くこともかもしれない。
すくなくとも私ならテストを書く。
なにかの参考になれば幸いである。

🦝 < テストはすんばらし