【ディップ｜26年新卒研修資料】TDD実装演習

Embed

Start on current slide

Slide 1

Slide 1 text

テスト駆動の実装演習 11:30 - 12:45 (75分)権奈悟‧吉本胡葉 TDD (Test-Driven Development)

Slide 2

Slide 2 text

Agenda 01 オープニング初めまして！ 02 TDDについて Test-Driven Development (テスト駆動開発) 03 デモ Fizz Buzz 04 テストについて良いテストとは 05 演習課題給与情報表示関数の実装

Slide 3

Slide 3 text

⾃⼰紹介

Slide 4

Slide 4 text

権奈悟こんなおプロダクト開発統括部/プロダクトソリューション部/メディアアプリ開発課バイトル→NEXT→はたらこ→バイトル iOSエンジニア吉本胡葉よしもとことは最近かぼちゃにハマってます⾟いのが好きプロダクト開発統括部/プロダクトソリューション部/メディアアプリ開発課 25卒⼊社からずっとバイトル Android エンジニア好きな⾷べ物はバナナとブルーベリー

Slide 5

Slide 5 text

dip_tech Copyright © DIP Corporation, All rights reserved. 5 講義の目的自分が書いたコードが正しく動いているか、常に確信を持てる状態を作る「テストが書きにくいコードは、設計が悪い」という気づきを与え、疎結合で責務が明確なコードを書く習慣をつける「動けばいい」ではなく、将来の自分やチームが安心してリファクタリングできる状態を維持する責任感を養う

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

質問 TDDについて知ってることを教えてください

Slide 9

Slide 9 text

リファクタ TDDとは従来の開発テスト駆動開発 (TDD) → Test-Driven Development (テスト駆動開発 ) テスト駆動開発とは、テストファーストな開発手法の 1つ。プログラムを書き始める前に、まずそのプログラムが正しく動くか確認するための「テストコード」を先に書く。実装実装 → テストテスト → →

Slide 10

Slide 10 text

TDDのメリット早い段階で不具合を検知最低限のコードで実装するため、シンプルで不具合が少なくなる。早期発見でリードタイムが短縮要件/仕様を理解しやすいテストコードを書くために仕様理解が必要となり、仕様への理解が深まる開発者の負担を軽減変更のたびにテストが実施でき、プログラムを壊していないか確認しやすい。心理的負担が軽減

Slide 11

Slide 11 text

TDDの3つのサイクル Red (失敗) まだ存在しないコードのテストを書く / 実行して、正しく失敗することを確認する（仕様の定義） Green (成功) テストを通すためだけの「最低限」のコードを書く Refactor (改善) テストが通った状態を維持したまま、コードを綺麗にする / 重複の排除、命名の変更、設計の整理を行う Red-Green-Refactor https://service.shiftinc.jp/column/4654/

Slide 12

Slide 12 text

デモ: Fizz Buzz https://ja.wikipedia.org/wiki/Fizz_Buzz

Slide 13

Slide 13 text

質問タイム(あれば)

Slide 14

Slide 14 text

TDDと従来の開発の比較従来の開発（テスト後回し） 1. 設計を考える 2. コードを書く（数百行〜数千行） 3. 動かしてみる 4. バグ発見 😱 5. どこが悪いか探す（数時間〜数日） 6. やっとテストを書く TDD（テスト駆動開発） 1. 小さなテストを書く（数分） 2. 最低限のコードを書く（数分） 3. すぐテスト実行 4. 通った！次のテストへ 5. 少しずつ機能が完成 TDDが適しているシステムの特徴 : 複雑なビジネスロジック・長期的な保守が必要な時

Slide 15

Slide 15 text

AI-DLCにおけるTDD 人間がボトルネックとなる AIがプログラムを早いスピードで生成しても、人間のレビューがボトルネックとなり、生産性は上がりにくい TDDを導入することでレビューがどう書かれているか (how)＜何を達成するか (what)に意識がむくテストコードが仕様書となり、レビュー効率が上がるテストを書く・実装・リファクタのフェーズがはっきりしている AIも今やるべきこと、必要な観点に集中して実装できる

Slide 16

Slide 16 text

テストについて

Slide 17

Slide 17 text

テストしやすい /しにくい単一責任の原則（ SRP）に基づく一つのモジュールは一つの責任のみを持つ依存関係の分離依存オブジェクトを外部から注入するモジュール化・分離各部分が独立しており、個別にテストできる純粋な関数外部状態に依存せず、同じ入力に対して常に同じ出力を返す小さく単機能な関数にするテストが用意になる依存関係が内部生成副作用が多い複雑な条件分岐、メソッドが長いテストケースが多くなる

Slide 18

Slide 18 text

良いテストとは : FIRST原則 Fast（高速）開発ライフサイクルのどのタイミングであっても実行でき、なおかつテストの結果をすぐに取得できる。 Independent（独立）どのような単体テストであれ、テストの結果が他の影響を受け、変化しないように独立している必要がある。 Repeatable（再現可能）テストは繰り返し実行が可能で、なおかつ繰り返しの実行で結果が不変であり、また異なる環境であってもこの性質が保たれるべきである。 Self-Validating（自己検証）実行結果を見て成功か失敗かが自動で判定される Thorough（網羅性） F テストは全ての実現したい正常系パターンを網羅すべき。単に実装したコードを 100%カバーするテストを考えるのではなく、全てのユースケースシナリオを網羅できるように考える。 I R S T

Slide 19

Slide 19 text

質問タイム(あれば)

Slide 20

Slide 20 text

TDD演習

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

dip_tech | Copyright © DIP Corporation, All rights reserved. 演習課題 Lv.1 お題：給与表⽰フォーマッター求⼈の給与情報を、ユーザーに⾒せるための表⽰⽤テキストに変換する関数を作ってください。ざっくり仕様 ● 下限⾦額と上限⾦額を受け取って、表⽰⽤の⽂字列を返す ● ⾦額にはカンマをつけて⾒やすくする ● 下限と上限が同じなら1つだけ表⽰する ● 下限と上限が違うなら範囲で表⽰する ● 五桁以上はバリデーションする ● 下限と上限が逆の場合：逆転 ● ⼊⼒された値がnull or undiﬁnd：数値以外はエラー ● 負の数がきた場合はエラー ● 最低賃⾦1000円

Slide 24

Slide 24 text

Slide 25

Slide 25 text

dip_tech | Copyright © DIP Corporation, All rights reserved. 演習課題 Lv.2 お題：応募締め切りカウントダウン求⼈の応募締め切り情報を、ユーザーに⾒せるための表⽰⽤テキストに変換する関数を作ってください。ざっくり仕様 ● 本⽇⽇付と締め切り⽇付を受け取る ● 締め切りまで1⽇以上あるなら「あと◯⽇で終了」と返す ● 締め切り当⽇なら「本⽇締切！」と返す ● 締め切りを過ぎていたら「掲載終了しました」と返す ● Date型で返却される ●

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

dip_tech | Copyright © DIP Corporation, All rights reserved. まとめ！今⽇の演習はシンプルなロジックでしたが、実務ではもっと複雑な仕様や条件分岐がたくさん出てきます。そういうときこそ「先にテストを書いて、仕様を固めてから実装する」 TDDの進め⽅が効いてきます。 AIに実装を任せる場⾯でも、テストがあれば「本当に正しいか」を⾃分で確認できる。ぜひ実務でも活⽤してみてください。

Slide 30

Slide 30 text

参考文献 SHIFT Inc. (2025) 「テスト駆動開発（TDD）とは？目的やメリット・デメリット、やり方を解説」 SHIFT Column https://service.shiftinc.jp/column/4654/ (最終閲覧日: 2026年4月16日)