見出し画像

「テストコード」との衝撃的な出会い

おとも

「テストコード」という言葉をご存じだろうか・・・

自分はソフトウェアエンジニアとして、十数年働いてきているが、特定の現場で長く働いていたこともあり、経験の偏った、非常に視野の狭いエンジニアとなってしまっていた。
「テストコード」を知らなかったのだ。

今回はテストコードとの出会い、そもそもテストコードとは？というところから、実際に自分が現場にテストコードを導入していくところまで紹介したい。


テストコードとの出会い

そもそもテストコードとの出会いはこの本だ

Python系VTuberサプーさんの書籍なのだが、この本はその表紙の見た目とは裏腹に非常に内容が濃い。初心者向けというより、中上級者向けの内容となっている。
そしてこの本の7章にあるのが
「バグがあるかも？　テストコードを書こう！」
だ。

ここでテストコードとの出会いを果たした。

テストコードとは？

そもそもテストコードとは何か？
テストコードとは、プログラムの動作を検証するために書かれるコードのことだ。
実際のコードが正しく動いているかを確認する為の専用のコードだ。

例えば以下のような足し算を実施するコードがあったとする。
本記事では以下のようなテストされるコードのことを、以後"プロダクトコード"と書く

class Calculator:
    def add(self, a, b):
        return a + b

これに対して、以下のようなコードで動作を確認する。これがテストコードだ。

class TestCalculator(unittest.TestCase):
    def test_add(self):
　　　　 self.calc = Calculator()  # 各テストケースの前にインスタンスを作成
        self.assertEqual(self.calc.add(2, 3), 5)   # 2 + 3 = 5
        self.assertEqual(self.calc.add(-1, 1), 0)  # -1 + 1 = 0
        self.assertEqual(self.calc.add(0, 0), 0)   # 0 + 0 = 0

テストコードの何が衝撃なのか？

テストコードがない場合、作成したソフトウェアのテストはどうするのかというと、これはもうひとつずつ手で確認するしかない。
現場でよくあるのが、Excelで手順書を作成し、デバッカで動かしてその動作を確認していくというものだ。
この方法の問題点は、手順書の作成にかかるコスト（労力*時間）に加えて、テストの実施にもコストがかかるという点だ。それも、テストの実施のコストはテストをやり直すたびに毎回かかってくる。

テストコードの場合、テストコードを書くのにコストはかかるが、テスト実施にはほとんど時間がかからない。（規模にもよるが、数m秒から数秒程度）
そのため、再テストが非常に容易に出来る。
Mockという仕組みを用意すれば、テスト対象を絞ったより踏み込んだ確認が容易に出来ることがあげられる。

自動テストとテストコードの違い

よく「自動テスト」という言葉を聞くが、
自動テストはソフトウェアテストを自動で行うこと全般を指す。これにはテストコードを使用しない、UIテスト（画面動作テスト）なども含まれる。
テストコードは、テストを自動化する為のプロセスの一つ。主に単体テストでの自動化で使用されるプロセスとなるようだ。

UIテストの自動化はコスパ悪い

この辺りの本を読み漁っていると、やはり自動テストといってもUIテストは現実的な運用はかなり難しいようだ。
対応自体は（膨大な）時間をかければ可能だが、その後の仕様変更などでテストはすぐに使えなくなってしまう。そしてそのメンテナンスに追われるか、テストが破棄されるかいずれななのだそうだ。（恐ろしい・・・・）

テストコードを書くメリットは決してばかにならない

テストコードはテストを自動化する為のプロセスの一つと書いたが、色々と学んでいくと、テストコードは単にテストにかかるコストの削減するものではなく、非常に多くのメリットがあることが分かってきた。

・再テストがいつでもすぐ実行できるので、リファクタリング（動きを変えずに、作りをよりよく変更すること）が積極的に行えるようになる。
・プロダクトコードの修正時、再テストにほとんど時間がかからない。
・新たな機能を追加した際に、元々あった機能が壊れる"デグレード"は回避できる。
・設計段階から、テストしやすいコード（クラス間が疎結合な構造）に向かっていく。
・テストコード自体が、動くドキュメントになる。テスト対象のコードがどのようなものなのかを調べるのに非常に役に立つ。

いずれも小さなことではあるが、決してばかにはならない。
特にリファクタリングが積極的に行えるようになることは、プロダクトコードが常に成長していくことを示すので、これこそがまさにテストコードを導入する目的となり得る大きなものだとなる。

テストコードについてもっとちゃんと学びたい！

テストコードについてもっと学びたいと思い、色々と書籍を漁った。
色々見たが、結局これだ。
少々お高いが、内容がめちゃくちゃ濃いので読み終わった頃には安すぎると感じた。

ここでは単体テストのことが網羅的に書かれている。
本書にある単体テストとはテストコード用いた単体テストのことである。（業界では、単体テスト＝テストコードを記述するものという認識が一般的なようだ）

単体テストとはそもそも何か？
単体テストにおけるよりよいテストコードの書き方。
単体テストをどこまで導入するのか？モックの利用はどこまでするのかなど

単体テストについては以下記事にもまとめた。


テストコードを書く習慣を現場に導入したい

今は、テストコードを書く習慣を今の現場に導入したいと思っている。
今はテストコードとは？というところからの手探りではあるが、まずは自分の作業の中で自分自身がテストコードを書く技術とそのメリットを理解したうえで、チームメンバーに波及させていきたいと考えている。

Excelで手順書を書くテストはとても辛いし退屈なので、テストコードを増やすことで、これを少しでも減らしていけたらと思っている。

いいなと思ったら応援しよう！