完全に自分用のメモです。
（見る場合は、テキトーに流し見してください）
たとえば、最終的に👇の関数を実装しなければいけないものとします。
const add = (a:number, b:number ) => {
return a+b;
}★★★
TDDではまず、👇のような感じのテストを書きます。
expect(add(1,1)).toBe(2)ただ、このテストは失敗します。なぜなら、まだadd関数を定義していないからです。
なので👇のようなadd関数を「仮実装」します。
const add = (a:number, b:number ) => 2; //とりあえず2を返すこのように、「とりあえずテストを通すためにテキトーに書いたろ」なコードのことを「仮実装」と呼びます。
つぎにリファクタします。リファクタは、コードの機能を変えずにきれいにすることです。なので「この書き方は見にくいな」みたいな部分を治すのだけやります。リファクタの順番は本コード→テストコードの順です。
それはさておき、👇のように修正してみます。
const add = (a:number, b:number ) => {
return 2; //とりあえず2を返す
}次に、もう一つテストを追して、本コードをまともな実装に戻そうと思います。
（「いや2の部分をa+bに修正すればいいだけじゃん」と思うかもですが、ここではその修正方法がわからないので、試しにテストをもう1つ追加しよう！みたいな感じだとします）
たとえば、👇のようなテストを追加してみます。
expect(add(2,2)).toBe(4)このテストを追加すると、テストが失敗するようになりました。なぜならaddは2を固定で返すからです。
なので、今回はaddを👇のように修正しました。
const add = (a:number, b:number ) => {
return a+b;
}お、どうやらどちらのテストも成功したようです。
このとき、「add関数をどう修正すればいいかわからないから、試しにもう一つテストを追加してみるか〜」な手法のことを「三角測量」と呼びます。
また、この三角測量によって「add関数は正しい状態になったな」という確信を得たとします。
このとき、add関数を「実装」できた･･･と言えます。
★★★
これがTDD周りのザックリした流れです。
レッド→グリーン→リファクタとも呼びます。
今回の場合、👇のような手順でしたが
テストを書く → 仮実装 → 三角測量 → 実装本来はaddという簡単な関数にここまで手間をかける必要はないので、👇でいいはずです。
テストを書く → 実装このように、テストからいきなり実装しちゃうことを「明白な実装」とよびます。
ちなみに、ちょいムズな実装ならこう👇かもしれません。
テストを書く → 仮実装 → 実装ムズかしい実装ならこう👇かもしれません。
テストを書く → 仮実装 → 三角測量 → 実装おわり
コメント