Zenn
🚀

【新人向け】テストリストを最初に作成してレビューしてもらおう

に公開
Test
開発
新人
idea

私は実務歴約1年の新人エンジニアです．
1年ほど経つと，規模の大きい開発タスクを任されるようになってくるかと思います．
本記事では，中規模以上の開発タスクを進めていく中で，「最初にテストリストの作成とレビューをしてもらったら開発がスムーズに進んだ」という体験談をまとめました．

対象読者

  • 実務経験1年未満〜3年程度
  • 開発の手戻りを防ぎたい
  • 相談する際のコミュニケーションコストを削減したい

最初にテストリストの作成とレビューをする

設定

説明を簡単にするため，ECサイトの機能全般の開発を任されたと仮定しましょう．
主な機能は以下とします．

  1. 商品一覧機能
  2. 商品追加機能
  3. 商品編集機能
  4. 商品削除機能

プロセスの変化

通常，以下のようなプロセスで実装とレビューが行われると思います．

  1. 一覧機能のプロダクトコード実装
  2. 一覧機能のテストコード実装
  3. 1,2のコードレビュー
  4. 追加，編集，削除機能についても同様に，1~3のプロセスを回す．

今回，私は以下のように進めました．

  1. 一覧，追加，編集，削除機能のテストリストを書く．
  2. 1のテストリストをレビューしてもらう
  3. 一覧機能のプロダクトコードを書く
  4. 一覧機能のテストコードを書く
  5. 3,4のコードレビュー
  6. 追加，編集，削除機能についても同様に，3~5のプロセスを回す．

前者では一通りコードを書いてからレビューをしてもらうのに対し，後者では序盤にレビューを挟むのが大きな違いです．

テストリストの書き方

「テストリストはこう書くべき！」というのは特になく，実装者・レビュワー・チームで相談して決めると良いでしょう．
例として以下の2パターンあると思いますが，私はパターン2を採用しました．テストコードを書き始める際，テスト全体の構造設計を事前に合意していた方が書きやすくなるためです．

パターン1：テスト項目を列挙する

- 販売中の商品が全て表示されていること
- 売り切れた商品は表示されないこと

パターン2：テストシナリオを疑似コードで書く

※RSpecのSystem Specを使用してると想定

RSpec.describe "ECサイト", type: :system do
  describe "商品一覧" do
    it "販売中の商品がすべて表示されること" do
        # "販売中"の商品A・Bを作成

        # 商品一覧画面を開く

        # 商品Aが表示されてることを確認
        # 商品Bが表示されていることを確認
    end

    it "売り切れ商品は表示されないこと" do
        # "販売中"の商品Aを作成
        # "売り切れ"の商品Bを作成

        # 商品一覧画面を開く

        # 商品Aが表示されてることを確認
        # 商品Bが表示されていないことを確認
    end
  end
end

メリット

手戻りの防止

最初に言語化・構造化をすることで，自分の中で仕様の整理ができ，エッジケースやTODOの洗い出しが進みます．またテストリストのレビューを通すことで，第三者視点で抜け漏れを指摘してもらうことができます．
実装を進める途中で「こんなエッジケースがあったのか！実装変更しなきゃ！」という悪夢が減るのを期待できます．

コミュニケーションコストの削減

私の場合，普段よく相談に乗ってくれる方がコードレビューもしてくださってます．
以前までプロダクト・テストコードのレビューを依頼するときに初めて，仕様を把握してもらうプロセスになっていました．その場合，設計・実装段階の相談のたびに仕様の説明をする必要がありました．今回，テストリストを作成した段階でレビューを挟むことで，スムーズに設計・実装の相談ができるようになったと思います．

また，コードレビューでも的を射た指摘を受けられるのも期待できます．
システムの仕様や制限があり，仕方がなくイレギュラーな書き方をした部分があると仮定しましょう．テストリストで仕様を事前共有しておくことで，その部分のレビューに頭を悩ませることがなくなり，実装者・レビュワー双方の時間を節約できます．

制限/注意点

具体的な方法やメリットについて色々書きましたが，全てのチーム・開発タスクにとって有効とは限りません．制限や注意点をリストアップします．

開発規模が小さいとき

小規模タスクの場合，テストリストの作成とレビュープロセスが逆に負担になってしまう可能性もあります．自身の力量やタスクの規模と相談してみましょう．

テストを書く文化がチームにない

今回私は，擬似的なシステムテストを書く方法を採用しましたが，そもそもテストコードがない，というチームもあるかと思います．その場合，テスト項目を列挙するだけでもやってみましょう．自分の考えを整理するだけでも，仕様洗い出しの点でかなり効果があります．

まとめ

最初にテストリストの作成とレビューをしてもらうと良かった，という体験談を紹介しました．
テストリストを最初に作成するだけでも十分効果を感じられるので，ぜひ試してみてください．

Discussion