自動テスト導入のポイント

チーム内で自動テストの目的を明確にし、共有すること

当たり前のように聞こえますが、最も大事なことです。
目的が明確になってないと、効果的な自動テストの導入ができません。

「言われてるからとりあえず作る」という人が多い気がします。
それだと、
・後々、メンテナンスが大変なテストコード群が出来上がる。
・自動テストとしてのメリットが享受できない
という状態になってしまいます。

自分達のチームは、何のために、何を担保したくて、テストコードを書いているのか？をちゃんとドキュメント化して、説明の場を設けて、チームに浸透させることが重要です。

自動テスト可能なコードになっているか

まずは3層構造

自動テストを導入しようと思っても、3層構造になっていないと、自動テストを効果的に導入できません。

3層構造になっていなくても、自動テストを書くのが不可能ではないです。
ですが、3層構造になってない状態で全層のEtoEテストを書くと、メンテナンスが非常に困難になっていきます。

少しDBのカラム構成を変えただけで、本来関係ないテストコードまでが影響を受けてしまい、あまり詳しくない人がテストコードを修正するハメになり、とりあえずテストを通すための修正になり、テストの意味がなくなるようになっていきます。

テスト可能性＝適切な分割がなされているか

テスト対象コードが少なければ少ないほど、テストは容易になります。
数行のメソッドのテストを書くのと、100行のメソッドのテストを書くのでは、
前者の方が容易なのは明らかでしょう。

これが、最低限、3層構造にしておきたい理由です。
3層のうち真ん中のサービス層は、ビジネスロジックを書く場所なので、
APIによって全く違うロジックになっています。

サービス層を自動テストしやすくしておくには、
サービス層の中も適切にクラスが分割されている＝適切なコンポーネント構成となっている方が良いです。

テストケースは「状態」を全網羅するよう作っておく

どういうテストケースを作っておけば良いのか？という話題が必ずあがります。

それに対しては、その業務に対して存在しうる「状態（ステータス）」を全網羅するように作ってください。
それが、テストケースの過不足のない作成根拠です。

テストケースを挙げる時は、必ずマトリクス（パターン表）を作成してください。

マトリクスを作っておかないと、必ずテストケースは漏れます。
また、マトリクスがあると一目でこの業務にはどんな状態がありうるかわかります。
それによって、違う人がメンテナンスする時も理解しやすいし、レビュワーもレビューしやすくなります。

良い自動テストコード群はピラミッド型

テストケースは、対象範囲が狭いテストケース＞対象範囲が中ぐらいのテストケース＞対象範囲が広いテストケースとなるのが良い。
いわゆる、ピラミッド型になる。

一方で、アンチパターンとされるのがアイスクリームコーン型なので覚えておこう。自分達のテスト戦略が、アイスクリームコーン型になりそうな方向に動いていたら、戦略修正が必要である。

アイスクリームコーン型が脆い理由は、自動GUIテストやインテグレーションテストはコードが長く、複雑になることが挙げられる。
それらのテストを書くと、事前のデータ準備や評価項目が多くなり、失敗する可能性が上がる。
失敗して修正したい時も、テストコードが長くて複雑になっているため、修正が難しくなっている。
その結果、テストコードが放置され、意味をなさなくなっていく。

だから、ピラミッド型を意識して、ユニットテストで土台をしっかり固める方針で考えていくことが重要である。

自動テストは人が書くので間違っている可能性がある？

私は自動テストを書きたくないと思っていたときは、
「人が書くからテストコード自体が間違ってる可能性あるでしょ」
と思っていた。

しかしそれは、自動テストも手動テストも同じである。
手動テストも人がテストケースを考えるのだから、
テストケースの条件や期待値が間違っている可能性がある。

自動でできるものは、自動でやらせた方がいい。
繰り返しのテストが非常に楽になるからである。