はじめに
JISOUの勉強会でテスト駆動開発(以下TDD)というのを体験したので簡単にまとめようと思います。個人やインターンではやったことがない手法だったのでかなり難しかったです。
勉強会は最初に以下のtdd boot camp 2020 onlineという動画を視聴し、その後apiからデータを取得する簡単なアプリをTDDでペアプロしながら作っていくという流れでした。
TDD(テスト駆動開発)とは?
Test Driven Developmentの略称で、従来の設計→実装→テストではなくテスト→実装→リファクタリングを繰り返していくプログラム開発手法のこと。テストから書くことで仕様を深く理解できたりバグを早い段階で見つけられるのでプロダクトの品質が高まるというメリットがあるが、慣れるまでに時間がかかることや開発コストが大きくなるなどのデメリットもある。
TDDの基本的な流れ
以下tdd boot camp 2020 onlineで紹介されていたTDDの基本サイクルです。
- 次の目標を考える
- その目標を示すテストをかく
- そのテストを実行して失敗させる(Red)
- その目的のコードを書く
- 2で書いたテストを成功させる(Green)
- テストが通るままでリファクタリングを行う(Refactor)
- 1~6を繰り返す
勉強会ではjson placeholderからpostsのデータを取得してきて表示させるという簡単目な実装をTDDで行いました。長くなるので今回はタイトル表示の部分だけを基本サイクルに沿って行なっていきます。
1. 次の目標を考える
ここでは実装する機能をTODO項目にしていきます。実装の順番としてはテスト容易性が高いものから進めていきます。最初はどのようにTODO項目を作ったりテスト容易性が高いものを判断するのかが難しいですが、ここは設計の技術書を読んだりとにかく経験を積むのが大事みたいです。
今回TODOは以下のようになりました(かなり省略していますが)。
- ユーザーはwebサイトのタイトルを見ることができる
-
ユーザー投稿の一覧をみることができる-
ユーザーは投稿のタイトルを見ることができる -
ユーザーは投稿の本文を見ることができる
-
「json placeholderの/postsから全データを取得する」ではなく「ユーザーは投稿の一覧を見ることができる」のようにユーザー視点で書かれた説明のことをユーザーストーリーというみたいです。
2. その目標を示すテストをかく
「ユーザーはwebサイトのタイトルを見ることができる」というテストをJestで書いてみます。実装はReactで行います。
describe("ユーザーはwebサイトのタイトルを見ることができる",()=>{
test("「demo app」というタイトルが表示されている",()=>{
render(<App />)
expect(screen.getByTestId("title")).toHaveTextContent('demo app');
})
})
3. そのテストを実行して失敗させる(Red)
当たり前ですが2で書いたテストはまだAppの中身を実装していないのでエラーになります。このようにテストが通らないことをわかっていてエラーが出た場合ナイスレッドといいます。(何が原因でテストが通らないか予想してからテストを実行するといいらしい)
4. その目的のコードを書く
Appの中身を書いていきます。リファクタリングの工程は後にあるのでこの段階ではコードの綺麗さ等は特に気にしなくて良いです。
function App() {
return (
<>
<h1 data-testid="title">demo app</h1>
</>
);
}
export default App;
5. 2で書いたテストを成功させる(Green)
これでテストがPASSするようになったと思います。このようにテストが通ることをわかっていてPASSした場合はナイスグリーンといいます。
6. テストが通るままでリファクタリングを行う(Refactor)
テストが通る状態のままで実装コード、テストコードともに必要な箇所をリファクタリングしていきます(今回は特にないですが)。リファクタリング自体は無限にできてしまうので5分~10分と時間を決めてやるといいそうです。
7. 1~6を繰り返す
今回は単純な実装でしたのでこれで終わりなのですが、実際は以下のように1つの機能実装を細かいTODOに分けて実装していくので1~6のステップを繰り返していくことになります。
- ユーザーはwebサイトのタイトルを見ることができる
-
ユーザー投稿の一覧をみることができる
- ユーザーは投稿のタイトルを見ることができる
- ユーザーは投稿の本文を見ることができる
気づき
TDDは難しい
一言で感想を言うととにかく難しかったです。普通に実装から入ればすぐ終わりそうな要件でもテストから入ることでかなり苦戦しました(結局最後まで作れなかった)。個人で小さなアプリを作る分にはTDDは必要ないかなと思いましたが、実務規模の品質が大事になってくるアプリであれば重要になってくるのかと思います。
ペアプロ楽しい
1対1のペアプロをあまりやったことがなかったので新鮮で楽しかったです。また1人でやるより作業に集中できますし、自分の知らないことも色々学べたのでまた機会があればやりたいです。(自分の技術力不足でペアの方には迷惑かけましたが😅)
おわりに
ここに書ききれてないこともたくさんあるのですが、TDDの概要は大体書けたと思います。また必要に応じて深く学びたいと思います。(以下の本がおすすめみたい👇)