単体テストという言葉の意味が人によって異なるのでややこしいのだけど、ここで私の言う単体テストは「関数やメソッドを単体で取り出して、そのインタフェース部分と内部実装に着目して実施するテスト」のことである。
10年以上も職業プログラマをやっているにも関わらず、今年一番の収穫が「ちゃんと単体テストしようぜ!」であることに、忸怩たる思いが無くもない。
とはいえ、何しろ年末になって趣味の一環で公開しているC++ライブラリの単体テストを書いたら潜在的にゼロ除算を引き起こしうるバグとかユースケース的に割とヌルポインタアクセスエラーを頻発しそうなバグとかを見つけてしまった訳で、そりゃあ「やっぱり単体テストはやらないとアカンよね」という感想を抱くものである。
ちなみに、もしこの件が無かったとしたら、今年の感想は「やっぱりLint/静的解析ツールを使って静的テストするべきだよね」だったと思う。
今年の前半は久しぶりにJavaScriptとPythonに触れる機会があった。JavaScriptについてはESLintを導入してnpm run
で全コードをチェックできるようにしたし、PythonについてはVisual Studio CodeにPython用拡張機能を入れた上で型ヒントを書くようにした。
後半にはそこそこ量のシェルスクリプトをShellCheckでチェックするようなこともやった。
モダンな静的型付けのコンパイル型言語における静的テストは「コンパイラが頑張る」という方向で進んでいるように思う。
一方で動的型付けのスクリプト言語では、処理系本体による静的テスト性能がどうしても低くなる点をLintのような外部ツールで補完しつつ、それでも漏れる部分は動的テストである単体テストでカバーする方向であるように思う。
そんな中で、TypeScriptだとか、Pythonの型ヒントだとか、静的テストの効果を高めるための仕組みが浸透しつつある点は少し興味深い。
――ということを書こうかなと思っていた矢先に単体テストで初歩的だけど致命的なバグを見つけたのである。
……ツールによる静的テストは便利だけど、それとは別に、やっぱりちゃんと単体テストせなアカンね。