UIコンポーネントテスト（結合テスト）

UIコンポーネントライブラリを書くならsotrybookを書いて確認した方が早そう？
→チェック観点が抜けることがあるのでその点が解決されるのであればよさそう？
→複雑なUI変化になるなどドキュメントの役割として使えそう

UI見てもわからない、リンクなどの確認ならアリかも。
でも、ここも普通のテストでもいいかも

アクセシビリティの観点から記載すると、グループとして識別できるようになど考慮することが良いのでメリットがあるかも

スナップショットでhtml文字列として外部ファイルに保存できるのでこれはアリかも。
https://amzn.asia/d/07SwdwVV

TDD

TDDのゴール

動作するきれいなコード。
テストコードはドキュメントとしての性質も求められる。

TDDのサイクル

まず、動作するコードを作り、その後きれいなコードにする。

0. 最初に失敗するテストを書く。
   失敗させるテストでのエラーであることを確認することで、テストライブラリが正常に動いていることを確認。実装前にやることが重要。Jestでいうと下記。

test("this test will fail", () => {
  fail("This is an intentional failure");
});

1. テストリストを書く
   何をテストするか網羅的に先に書き出す。実装脳になったら視野が狭くなりがちなので。

2. テストを一つ選びテストを書く

• テスト容易性の高いものから選ぶ。一周目は何もない状態なのでテストが重くなってしまいがちのため。
  テスト容易性とは、観測が簡単であること、制御が簡単であること、対象が十分に小さいこと
• 慣れると重要度の高いもの=容易性が高いものに近づいていく
  完成したらこう使いたいという利用者視点でテストコードを記載する。
• テストは準備→実行→検証→（後片付け）の構造をもつ。これをTDDでは下から書いていく。
  検証
  期待値から書いていくので軸がぶれないことが重要。実行値はまだ未記入でok
  実行
  作る前に使うことで、使いやすいものであるか検証する。

test("1を渡すと文字列1を返す", () => {
// convert関数は数値を入れて文字列が返ってきて欲しい
  const actual: string = convert(1);
  expect(actual).toBe("1");
});

3. そのテストを実行して失敗させる（red）
   実装はしていないのでテストは失敗になる。
   実装コードの実行値と期待値が一致しないエラーのみ発生している状態。
   コードは2で既にできてそう。

4. 目的のコードを書く

• テストを成功させるためだけのコードを実装する。
  ここではコードの綺麗さは気にせず、必要最小限のコードを最短で実装。
• 例えば、下記のようなコードを実装し、エラーにならないか確認する。実装コードは間違いがないので（return "1"しているだけなので、コンパイラなどの処理系を疑うことになる。）、テストコードに間違いがあることになる。テストコードのテストコードなどはキリがないものなので、テストコードのバグが発生していないかここで確認。

export const convert = (a: number): string => {
  return "1";
};

• テストコード、実装コードともに不安がない場合は、明白な実装になるので、4~6をまとめてやってしまう。

5. 2で書いたテストを成功させる（Green）
   4にてテストコードにも問題ないことを確認している。

6. テストが通るまでリファクタリングを行う（refactor）
   リファクタリングとは、ソフトウェア外部から見た振る舞いを変えることなく、理解保守が簡単になるようにソフトウェア内部を綺麗にすること。
   TDDはもう少し狭めて、成功しているテストが成功しているままでコードを綺麗にしていくこと。これにより、定量で判断できるので安全に開発を進められる。
   終わりどきは、時間や重複を除去できたらなどある程度できたら終わりに。

7. 1のリストに改訂があればする

8. 2~7を繰り返す
   エラーが発生したときデバッグをする必要が出てくるので、下記のようにアサートを複数並べないようにする。（アサーションルーレット）理想的には一つのテストに一つのアサーション。
   また、ドキュメントとして成り立たないことになる。

test("1を渡すと文字列1を返す", () => {
    // 実行 & 検証
    expect(convert(1)).toBe("1");
    expect(convert(1)).toBe("1");
    expect(convert(1)).toBe("1");
    expect(convert(1)).toBe("1");
    expect(convert(1)).toBe("1");
    expect(convert(2)).toBe("2");
  });

上記の場合、下記が望ましい。

test("1を渡すと文字列1を返す", () => {
  // 実行 & 検証
  expect(convert(1)).toBe("1");
});
test("2を渡すと文字列2を返す", () => {
  // 実行 & 検証
  expect(convert(2)).toBe("2");
});

繰り返すときに各テストの不安や自信によって下記の歩幅を使い分ける

• テスト→仮実装→三角測量→実装
• テスト→仮実装→実装
• テスト→明白な実装

9. テストをドキュメント化する（テストの構造化とリファクタリング）
   抽象度が低いテストコードだけになると、後から見たときに実装コードをみて中身を把握しなければならずドキュメントの役割を果たせていないので、テストリストで作成したツリー構造を参考にテストコードもツリー構造にする。
   テストコードをツリーにしたとき、階層のレベル感があっているか注意する。

- [x] 数を文字列に変換する
  <!-- 上記だとテストが書きづらいので具体的なものに -->
  - [x] 1 を渡すと文字列"1"を返す　= 仮実装
  - [x] 2 を渡すと文字列"2"を返す　= 三角測量
- [x] 3 の倍数の時は数の代わりに「Fizz」
  - [x] 3 を渡すと文字列"Fizz"を返す = 仮実装 → テストコードに問題がないので三角測量を通さずリファクタリングをする
- [x] 5 の倍数のときは「Buzz」
  - [x] 5 を渡すと文字列"Buzz"を返す = 仮実装 → テストコード、実装コードともに不安がない場合は明白な実装

describe("convert関数は数を文字列に変換する", () => {
  describe("3 の倍数の時は数の代わりに「Fizz」", () => {
    test("3を渡すと文字列'Fizz'を返す", () => {
      // 実行 & 検証
      expect(convert(3)).toBe("Fizz");
    });
  });
  describe("5 の倍数の時は数の代わりに「Buzz」", () => {
    test("5を渡すと文字列'Buzz'を返す", () => {
      // 実行 & 検証
      expect(convert(5)).toBe("Buzz");
    });
  });
  describe("その他の数の場合はそのまま文字列に変換する", () => {
    test("1を渡すと文字列1を返す", () => {
      // 実行 & 検証
      expect(convert(1)).toBe("1");
    });
    test("2を渡すと文字列2を返す", () => {
      // 実行 & 検証
      expect(convert(2)).toBe("2");
    });
  });
});

また、このタイミングで不要なテストコードも消しておく。上記で言うと「2を渡すと文字列2を返す」は三角測量のために書いたテストであり、後から見てもそれが伝わらないかつ、何か意味のあるものとして消すことができないのでこのタイミングで消す。

describe("convert関数は数を文字列に変換する", () => {
  describe("3 の倍数の時は数の代わりに「Fizz」", () => {
    test("3を渡すと文字列'Fizz'を返す", () => {
      // 実行 & 検証
      expect(convert(3)).toBe("Fizz");
    });
  });
  describe("5 の倍数の時は数の代わりに「Buzz」", () => {
    test("5を渡すと文字列'Buzz'を返す", () => {
      // 実行 & 検証
      expect(convert(5)).toBe("Buzz");
    });
  });
  describe("その他の数の場合はそのまま文字列に変換する", () => {
    test("1を渡すと文字列1を返す", () => {
      // 実行 & 検証
      expect(convert(1)).toBe("1");
    });
  });
});

ライブコーディング

問題

1から100までの数をプリントするプログラミングを書け。ただし、3の倍数の時は数の代わりに「Fizz」、5の倍数のときは「Buzz」とプリントし、3と5両方の倍数の場合には「FizzBuzz」とプリントすること。

コード

https://github.com/expsh13/TDD_Boot_Camp_2020

https://www.youtube.com/live/Q-FJ3XmFlT8?si=9ZEm5cOOOHyts3u_