単体テストを書くならこんなふうに

Gaji-Labo フロントエンドエンジニアの茶木です。

みなさんは、テスト書いていますでしょうか？テストの重要性はたくさんの方が述べていて、蔑ろにできないものです。しかし、テストを書くのは正直しんどいですよね。

この記事では、自分なりにつかめてきた、あまり辛くなく、ありがたみを感じやすいテストの書き方の手順について個人的な見解をまとめます。特に単体テストについて心がけていることについて述べます。

結論

先に結論です。
新機能追加の単体テストは、コーディング前に書いておくのがおすすめです。

• コーディング前に単体テストを書く
• 機能追加から時間が経つほどテストを書くのは辛くなる

機能追加のタイミングで単体テストを書く

テストのない既存機能に後からテストを書くのは、実作業的および心理的に高コストです。

• 機能が作られた当初の想定を知るのは困難
• すでに組み込まれて問題なく動作している（ように見える）機能のテストを書くメリットを感じにくい

そのため、機能を作るタイミングで書く単体テストが、仕様を一番理解しており書きやすく、さらにテスト作成以降の変更作業のすべての保険となるため、一番利益が大きいです。

コーディング前に単体テストを書く

入力、出力、関数名を規定したメソッドなど、空の機能を作成し、まずテストを書きます。

function median(listA: number[]): number { 
  return;
}

describe("中央値", () => {
  it("要素数が奇数の場合はソートして真ん中の値を返すこと", () => {
    const res = median([-1, 2, 7, 3, 0]);
    expect(res).to.eq(2);
  });
  it("要素数が偶数の場合はソートして真ん中の2つの平均値を返すこと", () => {
    const res = median([-1, 2, 7, 3, 0, 8]);
    expect(res).to.eq(2.5);
  });
  it("要素数が0の場合は undefined を返すこと", () => {
    const res = median([]);
    expect(res).to.eq(undefined);
  });
});

機能実装はこの後に行います。これには以下のメリットがあります。

• テストを書くことで機能のスコープを明確にする
• テストは fail した状態から始まり、テストがすべてパスして完成となる

ひとつめは、機能の理解なしにテストは書けないため、あやふやな理解で実装作業を始めてしまうリスクを下げられます。また、テストを書くこと自体もコストなので、Nice to have のような機能を作り込むことを自制し、必要十分な機能に限定して作成できます。

ふたつめは、心理的なメリットです。
機能作成後にテストを書こうとすると、テストが付随作業に見えてしまい、テンションが上がらないのですが、先にテストを書いて進めると、完成までに、fail 項目がパスしていく様子を目にするためテストの有用性を感じることにもなります。

既存機能のテストは改修分だけでも書く

前述の通り、既存機能にあらためてテストを書く思考コストは、新機能にテストを書くよりも大きいです。また、テストを書かずに育ってしまった機能にテストを書くのは本当に辛いものです。

この場合は、機能改修のタイミングでその改修分だけでもテストを書くのをおすすめします。改修時に理解し、テストに起こされたものはドキュメントとしても価値があるため、以降の改修時には少しテストを書きやすくなるためです。

おわりに

テストはプロダクトの早期の不具合発見に繋がります。これはダイナミックな改修を大胆に行える環境をを確保することに繋がります。また、テスト自体が機能のドキュメントとしての価値を持ちます。大きなプロジェクトではメンバーの入れ替えも多いので、これらのメリットは計り知れません。

Gaji-Labo は、スタートアップ支援の会社です。
テストは、光が当たりにくいけれどプロジェクトとチームにとって長期的な成果につながります。「コードを書くだけではなく、チームワークを提供する」を意識して頑張っていこうと考えています。