【気づき】テストケース・テストコードの重要性
はじめに
現在、未経験からバックエンドエンジニアを目指して学習中です。
この過程でアルゴリズムをつくる練習で、テストケースをたくさん実行するのですが、
「なぜテストケースが重要か」という点が曖昧でした。
「ソフトウェアは品質が大事」「品質を担保するためにテストが存在する」
など、こういった類のコメントをたくさん拝見します。
しかし、それが意味することを理解していなかったことに気づいたので、わかったことをメモとして記録していきます。
今回挙げること以外にも重要な要素はたくさんありますが、今回はその中でも特に大きな気づきとなった点にフォーカスしてまとめていきます。
実際の取り組み
データ構造の選択とアルゴリズムの設計を取り組み中のプログラムで練習しているのですが、そこにはテストケースが既にたくさん用意されています。
このテストケースを実行し、全てクリアすることで課題をクリアできるようになっています。
例えば以下のような問題の構成と用意されたテストケースです。
class SinglyLinkedListNode{
constructor(data) {
this.data = data;
this.next = null;
}
}
function linkedListLength(head){
let length = 0;
let iterator = head;
while(iterator !== null){
length++;
iterator = iterator.next;
}
return length;
}
関数の入出力例
入力のデータ型： SinglyLinkedListNode<integer> head
出力のデータ型： integer
linkedListLength(singlyLinkedList([3,2,1,5,6,4])) --> 6
linkedListLength(singlyLinkedList([7,8,2,3,1,7,8,11,4,3,2])) --> 11
linkedListLength(singlyLinkedList([34,35,64,34,10,2,14,5,353,23,35,63,23])) --> 13
linkedListLength(singlyLinkedList([1])) --> 1
※ https://recursionist.io/dashboard/course/3/lesson/421 より一部引用
しかし、課題をクリアできても、その「意味」を曖昧にしたまま取り組んでいたのですが、そもそもテストは挙動を確認する以外に何が重要なんだ？と思い調べました。
気づきのきっかけ
なぜそのように思ったのかというと、
「もし自分がテストケースを実装するならどういう観点でこのようなテストケースを作るだろう？」
と思ったことがきっかけでした。
そのとき、テストケースは関数が正しく動作するかどうかのものさしになる、という程度の理解で終わっていることに気づきました。
実際の気づき
参考にさせていただいた記事
こちらの記事で以下のように書かれているのを見て、「そういうことか！」とわかった点があります。
テストコードとして書かれていれば、そのコードそのものがドキュメントのような役割も持ちます
※https://qiita.com/d-haru/items/930097f76f5d82f9079b より一部引用
ソースコードには、開発者の「こう動いてほしい」という思いが記述されるが、バグが含まれていたり、予期せぬ挙動をする可能性があるので、テストコードでこの期待が「実際にどう動くか」事実を記録するために使うことができると。
つまり、テストコードは、ある関数や機能が「どう動くべきか」という開発者の期待を、具体的な入力と出力のペアで明文化したものであり、これによって他の開発者と関数や機能の挙動・意図を共有できる、ということにつながるということです。
開発現場の声
テストコードがないプロジェクトはその後どのような運命を辿るのでしょうか？
行き着く先は、保守がしにくく、バグ修正や新規機能追加などにスピード感を出せないシステムです。
...
現実問題、「後でテストコードを書いていこう」というその「後で」の時間はほとんどのケースで存在しないことが多いです。だからこそ、最初からできる限りテストコードを書くべきだと感じました。
※https://zenn.dev/yuulab/articles/45dc33feaada62 より引用
気づきまとめ
- テストコードはモジュールの品質、ひいてはソフトウェアの品質にかかわる重要なドキュメントになること
- ソースコードは開発者の期待、テスト（結果）はリアルなデータ・事実であること
- テストコードがない状態は将来に負債を作ってしまうこと（保守性の低下・開発スピードの低下・工数増大など）
参考URL
Discussion