テストコードを書けない人間が案件でテストコードを書き始めて分かったこと

概要

この記事は、テストコードを書けない人間が実際に案件でテストコードの実装を求められ、右往左往しながらテストコードを書き始めて分かったことを書き出してみたものです。
（具体的なコードや技術スタック的な話はありません）

テストコードが書けない

自分はテストコードが苦手です。少なくとも苦手でした。
なんで自分がテストコードに対してここまで苦手意識があるのかちょっと考えてみました。

恐らく以下の2点が主な原因かなぁと思ってます。

• テストコードを書くツール（JestやTesting Library）に対する理解度が足りていない
• テストケースを洗い出せない

ツールに対する理解度が足りていないのはドキュメント読んだりすればどうにかなるお話ですが...（とはいえ、APIのモックなど難度の高いものはあると思います。ここで詰まる人も沢山いそう）

恐らくテストコード初心者が詰まる理由の1つが「テストケースを洗い出せない」という点にあるのでは、と思っています。（少なくとも自分はそうでした）

それを踏まえて、テストコードの目的や必要性を書き出してみようと思います。

テストコードってなんで必要なんだろ

テストコードを書く主な動機としては、以下の3点が挙げられそうです。

• テスト対象機能の品質担保
• テストを自動化し、負担を減らす
• デグレ（改修による意図しない不具合の発生）の防止

作った機能は正しく動作することを確認する必要があります。
また、太古に作った機能が新たに作った機能の影響で不具合を生じてしまう、ということもありがちです。

新機能リリースのたびにこのチェック全てを人間が手作業で行うのはめちゃくちゃに大変な作業ですし（極端な話どこで不具合が発生しているのか洗い出すために、全ての機能全てのページを網羅とかいう現実的ではないことが必要になる）、その分工数も必要になってしまいます。
その上、ヒューマンエラーによって不具合を残したままリリースを行なってしまうということもありがちだと思います。

これらの負担を減らすため、テストコードを実装することでリリース前に自動的にテストを実行し、品質を担保してしまおう、というのがテストコードの主な目的だという認識です。

個人的には、「デグレの防止」がテストコードを実装する大きなモチベーションになりそう。

テストコードに求めたいこと

そのテストコードが資産になり得るか、負債になり得るかの判断は、テストコードに求める事項を満たしているかどうかによるかと思います。

テストコードに最低限求めたい事項は主に以下の項目だと思っています。

• 機能の要件に沿ったテストコードがあること
• テストコードの内容に過不足がないこと

ここは特に初心者の方が勘違いしちゃうかもなのですが、（というか僕が勘違いしてた）

テストコードを書くこと自体が正義ではなく、要件を整理し過不足なく書かれたテストコードが正義と考えておくのが良さそうです。

要件を整理できないまま闇雲に書いたテストコードは、以下のような負債になりがちです。

• 「要件を網羅している」と誤認識したまま書いた不完全なテストコード
  • 品質保証ができず、テストコードの役割を全うできない
• 必要のない確認まで行おうとする膨れすぎたテストコード
  • １度のテストにかける時間が大きくなってしまう
  • 無駄なテストの実装に工数をかけてしまう

品質担保してリリース前のテスト作業を楽にするためにテストコードの実装に時間をかけたのに...蓋を開けてみるとその機能のテストが不完全で、結局手作業でテストをしなくちゃならない...

とか、

張り切ってテストケースたくさん作ったのに、大半不要だった上にめちゃくちゃ時間がかかるテストを作っちゃってた...

なんてことにならないように、その機能のテストコードを書く際には改めて要件を洗い出しておいたほうが良いと思います。

分かったこと

ここまでを踏まえると、「テストケースが洗い出せないからテストコードが書けない」というより、「テストを実施する機能について理解できていないから、実施したいテストの内容が分からないし、テストコードを書くモチベーションも湧かない」ということが分かりました。

ここまで書いておいて「それはそう」という終わり方で恐縮ですが...
「とりあえずテストコード書き始めよ〜！」となる前に、「この機能の振る舞いってどんなだっけ...」というところの確認からするのが大事そうです。

逆に、「その機能についてのテストケースを正しく洗い出せる」のであれば、「その機能の振る舞いや要件がちゃんと分かっている」と言えそうですね。

おわりに

調べてみると「テスト駆動開発」なる開発手法があるようで。

なるほど難しそうだなぁ、と思いつつ、テストケースを考える段階が設計と同じことをしていると考えるとめちゃくちゃ理に適ってるなぁと思った。もうちょいテストコードを書くのに慣れたらこれも実践してみよう。

いろいろ書いておきながらアレですが、自分はそこまでテストコードを書くモチベがない人間だな〜とこの記事を書きながら思いました。

（品質保証が大事なのは理解しているつもりですが、どちらかというと新機能をガリガリ作るほうが楽しさを覚える人間なので...）

まだまだテストについて理解できていないこととか多いので、色々知見が溜まったらまたアウトプットしたいな〜。