SlideShare a Scribd company logo
1 of 38
Download to read offline
TDDを実践してわかった
 TDDつまづくあるあると
自分なりの乗り越え方まとめ

    @remore
今日、
 僕たちが
経験すること
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
Kent Beck wrote:

TDDは分析技法および設
計技法であり、実際には
開発のすべてのアクティ
ビティを構造化するため
   の技法である。

 テスト駆動開発入門
    p199
「TDDは分析技法
および設計技法」
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
「TDD=テスト
  ファースト?」
「テストコードを書く
  だけでしょ?」
____
      /⌒ ⌒\
  /( ●) (●)\
/::::::⌒(__人__)⌒::::: \   簡単だお!
|        |r┬-|        |
\         `ー'´      /


       3か月前の@remore
____
      /⌒ ⌒\
  /( ●) (●)\
/::::::⌒(__人__)⌒::::: \   簡単だお!
|        |r┬-|        |
\         `ー'´      /


後に現実を知ることになります
今日はTDDをケントベッ
クのテスト駆動開発入門
    で学んだ後、
僕の前に⽴ちはだかった
  いくつかの現実と、
僕がそれをどう乗り越え
 てきたかを紹介します
※この物語は
割とノンフィ
クションです
@remoreについて
• ニジボックスでソーシャルアプリ開発
• アジャイルな開発手法の導入を進めてる
• 3か月前の自分:
 – TDDは実践経験なし
  • テスト駆動開発入門を読んだ知識だけ
 – PHPUnitのインストール方法と簡単な使い方
   はネットで調べて知った程度
TDD修行
         TDD修行の旅
            修行の

          ??????          |
                          ■
                         ■■
レガシーコード山脈
レガシーコード山脈               ■■■
           ▲▲▲▲▲
              ▲ ▲     ?????
                      ???????
   ▲ ▲ ▲ ▲▲▲ ▲ ▲ ▲▲
   ▲ ▲ ▲▲ ▲ ▲
    ▲ ▲ ▲       ▲
     ▲ ▲ ▲     ▲ ▲
      ▲ ▲ ▲ ▲▲▲ ▲
      ▲ ▲
       ▲ ▲      ▲
        ▲     ▲ ▲
           ▲▲ ▲ ▲
            ▲ ▲
             ▲ ▲▲
              ▲ ▲▲
               ▲ ▲▲
 ▽スタート地点
  スタート地点       ▲ ▲▲
                ▲
レガシーコード山脈
• テストコードのない実装が山のようにあ
  る。
• 山の住⺠はソースコードの変更をした後、
  周辺を含めて何も壊れていないことをき
  ちんと確認する。そのあとは、結果がう
  まくいくことを祈りながら暮らしている
  と言われている
僕が登った山
• 自社MVCフレームワークを使ったソー
  シャルアプリのレガシーコード
• 言語はPHP
• ソースコードは10万⾏
 – フレームワーク部分を除いて、Model,
   Controller, Viewだけなら4000⾏くらい
  ※有効コード⾏数ベース
• テストコード⾏数は0
TDDつまづくあるある①

レガシーコード(テストコードのな
い実装)の山を目の当たりにして戦
意を喪失する。
(TDDをどのように現実の問題に適
用すればよいか、妙案が浮かばずに
途方に暮れている状態)
あると思います
(ありました)
考え方:我流でGO
絶対的に正しいTDDの適用方法を知りたくなるのは人情だけど、多分状況は千
差万別なので、それを始めから⾒つけるのは困難。

失敗して傷つきながら自分なりのプラクティスを作っていく:

•   MVCモデルでテストコードってどこから書けば良いのか
    – Model → Controller → Viewの順番でテストコードを書いていく方針でやってます

•   Controllerにかなりロジックがあって、テストできない部分が多い
    – これ、地味にかなりヘコみます・・「面倒くさっ」ってなる
    – まあ、Bad Designてことですよね。リファクタリングしないとね。Modelにテスト
      コード書き終わったらやろう。
    – テストコードを書きながら、Modelにコードを移していくイメージ

•   Viewのテストコードはどうしようかな
    – 仕組み上難しい場合も多そう(viewの中でechoしてたりだとか)
    – @remoreの場合は、Viewにはテストコードを書いていない。(その代わりソース
      コードレビュー他の設計技法は適用)
時間がかかりやすいところ
•   Modelのコードだけテストしようとしたけど、フレームワークの初期化処
    理を経由しないとModelに配置されてるオブジェクトを使えなかった
    – PHPUnitからModelを呼び出すために、テスティングフレームワーク内に、フレーム
      ワークの初期化処理だけを抜き出したphpスクリプトを新たに用意した
       •   バッドノウハウでごめんなさい


•   テストを実⾏する度に、テストコードから呼び出したModelのメソッドに
    よってDBのレコードが変化していくので、何も考えないでテストを書いて
    いくと、直前に成功していたテストコードが通らなったりする
    – setUp()とtearDown()を活用して、どんな環境でも失敗しないフィクスチャを作る
    – 例:
       •   setUp()で前回挿入したレコードを削除する
       •   テストコード内で使用するユーザ情報も設定しておく
    – Datasetを比較するほど細かく内容をテストすることが現実的だと思えなかったので、
      PHPUnitのデータベーステスト(PHPUnit/Extensions/Database/Testcase.php=
      DbUnitのポーティングを利用)はやらなかった
    – StubやMockは使っていない
       •   初めから使うことを想定して設計しておかないと使いづらい印象
細かいけど書いておきたいこと

• PHPUnitだと、1テストファイルに1テストクラス
  (PHPUnit_Framework_TestCaseの継承)しか書けない(っぽ
  い)
  – テストファイルを”*Test.php”っていうファイル名にしておけば、
    phpunitコマンド実⾏時にフォルダ名を渡すことでフォルダ内全体(ネ
    ストされているフォルダ含む)をテストしてくれる

• コードの可読性を重視して、テスト関数名に日本語でテストの目的
  を書いておくのがオススメ(文字コードはUTF-8であればテスト実
  ⾏可能)
TDD修行
         TDD修行の旅
            修行の

           生産性の
           生産性の谷          |
                          ■
                         ■■
レガシーコード山脈
レガシーコード山脈               ■■■
           ▲▲▲▲▲
              ▲ ▲     ?????
                      ???????
   ▲ ▲ ▲ ▲▲▲ ▲ ▲ ▲▲
   ▲ ▲ ▲▲ ▲ ▲
    ▲ ▲ ▲       ▲
     ▲ ▲ ▲     ▲ ▲
      ▲ ▲ ▲ ▲▲▲ ▲
      ▲ ▲
       ▲ ▲      ▲
        ▲     ▲ ▲
           ▲▲ ▲ ▲
            ▲ ▲
             ▲ ▲▲
              ▲ ▲▲
               ▲ ▲▲
 ▽スタート地点
  スタート地点       ▲ ▲▲
                ▲
生産性の谷

• レガシーコード山脈の難所の一つ
• 谷には開発者の不安を取り除くことができ
  る財宝が眠っていると言われている
• 「テストコードは要らない。最速で実装を
  終えよう。」という言い伝えを守り、山の
  住人はこの谷には近づかずに生活している
僕が落ちた谷
• 明らかに開発速度が落ちた
 – この時期は「@remoreさん、今何してんすか?」と
   いうリーダーからの問いに答えるのが怖かった

• 一時期、TDDから離れみたが、TDDをしないこと
  によって、テストコードが取り除いてくれていた
  不安が確かにあったことに気付かされた

• まあ、結局、開発速度が遅くなるのは自分が経験
  不⾜なだけ
TDDつまづくあるある②

思ったよりもテストコードを書くと
開発が遅くなって(なったように感
じて)しまい、戦意を喪失する。
(TDDをやった方がいいと頭ではわ
かっていても、スキルが無いが為に
テストコードを書かない方がローリ
スクだと思い込んでしまう状態)
あると思います
(ありました)
とにかく経験値を積む[書き方編]
@remoreの場合、こんな経験を積んでいきました

• 例題演習
 – ケントベックのテスト開発入門を写経したり
   • 三角形を判定する関数をTDDで書いたり
   • 演習問題と解答例をgithubに置いてます。
     – https://github.com/remore/StudyTDD
 – FizzBuzz()をTDDで書いたり
• 業務でレガシーコードにテストコードを追加した
  り
• 新しく開発したツールやアプリにテストコードを
  書いていったり
とにかく経験値を積む[運用編]
• 環境構築
 – Jenkinsのインストールを繰り返し⾏った
 – PhingやXdebugも使ってみた
 – PHPUnit以外のテスティングフレームワーク
   も試してみた
  • PEAR非依存のlimeやSimpleTestならインストー
    ルにつまづくこともなくてこちらもオススメ
• 必要だった覚悟とか
 – 開発効率が下がったと思った分は残業してで
   も同じパフォーマンスを出すつもりでやる
もがいているうちに
 費用対効果について考え出した
• テストコードは1メソッドに対して1テストするだけで
  も違う
 – 「TDDは分析技法および設計技法」
 – 1メソッドが無理なら、1つのクラスに対して1つテスト
   コードを書くだけでも全然違う
   • テストファーストをガリガリ回すのとは違っちゃうけど
 – 何が違うかというと、こんなことを確認させてくれる(テ
   スト駆動開発入門 p126より抜粋)
   • 機能はどこに所属するのか。既存のメソッドの修正なのか、既
     存クラスの新規メソッドなのか、新しい場所に実装される既存
     のメソッドなのか、新規クラスなのか。
   • どのような名前をつけるべきなのか
   • 正しい答をどのようにチェックするのか
   • 正しい答えは何か
   • このテストから他のどのテストが提案されるのか
費用対効果について
       いま考えていること
• 作成するテストのパターンとボリュームは柔軟に考えればよい
 – Kent Beckは「条件分岐、ループ、操作、多相性」の4つをテストする
   ことを推奨しているけどね
 – 無理にテストコードを追加しすぎると、テストコード地獄(書いても
   書いても終わらない)にハマる
 – でも自分の中の不安は無視しちゃダメ

• 例えば、デグレが頻出してる部分だけテストコードを書きながらリ
  ファクタリングしてみるとか
 – いきなり全部リファクタリングしようとしないこと。コードの量が⼤
   きい場合は、十分に小さいサイズにリファクタすることで分割しなが
   らテストコードを追加していく。

• それとか、他の設計手法を交えることで割り切ることも時に有効
 – 例:Viewのコードは不安が少ないからテストコードは書かずにソース
   コードレビューだけしておこう
TDD修行
         TDD修行の旅
            修行の

           生産性の
           生産性の谷         |
                         ■
                        ■■
レガシーコード山脈
レガシーコード山脈              ■■■
           ▲▲▲▲▲
              ▲ ▲     自己満足の
                      自己満足の砦
   ▲ ▲ ▲ ▲▲▲ ▲ ▲ ▲▲
   ▲ ▲ ▲▲ ▲ ▲
    ▲ ▲ ▲       ▲
     ▲ ▲ ▲     ▲ ▲
      ▲ ▲ ▲ ▲▲▲ ▲
      ▲ ▲
       ▲ ▲      ▲
        ▲     ▲ ▲
           ▲▲ ▲ ▲
            ▲ ▲
             ▲ ▲▲
              ▲ ▲▲
               ▲ ▲▲
 ▽スタート地点
  スタート地点       ▲ ▲▲
                ▲
自己満足の砦
• 無関心と自信喪失に満ちた砦
• レガシーコード山脈を越えると⾒えてくる
• どんなに速くテストコードを書いても、テスト
  コードのおかげで潜在的なバグを修正できても、
  複雑に作られた自己満足の砦を抜け出すことは困
  難と言われている
• テストコードが通らなくて時間をとられてしまい、
  自信を失い、心が折れる旅人も多い
意外に多くの勇者が一人で燃え尽
  きてるんじゃないか説
• 自己満足という側面
 – どんなに速くテストコードを書いても、
 – テストコードのおかげで潜在的なバグを修正できても
 – 誰にも褒められない

• 自信を失いやすいという側面
 – テストコードが通らない時間は単純に苦痛
 – テストが通らない(=レッド)まま数時間使ってしまった
   時の無⼒感は異常

• 理想に燃えて始めたはずのTDD。その理想が仇になっ
  て、理想と現実のギャップがここでボディーブローの
  ようにきいてくる
TDDつまづくあるある③

かけた努⼒の割に報われ難いように
思い込んでしまい、次第に戦意を喪
失していく。
(上手に説明しないと他人からは理
解されにくいことがままあって、や
さぐれてるうちに次第に熱が冷めて
元のレガシーな頭に戻っていく)
あると思います
(ありました)
アウトプットを心がける
• 誰かに話す(共感してもらう)
 – 会社でTDDしててつまづいたら同僚に
   • そしてテストコードを追加したいと思ってくれるチームのリー
     ダーやメンバー、同僚、勉強会の皆さんに感謝を
 – プライベートの開発でつまづいたら勉強会で
   • というわけで、僕のここ数か月のつまづきをお話しさせても
     らって英気を養ってます。TDDBC in Tokyoの皆さんありがと
     うございます。
 – 勉強会を主催しちゃうのも一つの手

• 成果を上手にアピールする
 – Assertを追加したテストコードをリポジトリにcommitす
   る時、堂々と”25Assert追加”のようにコメントに書く事
   を習慣化する
 – 勉強会でLTさせてもらったりブログを書いて反響を頂いた
   り
アウトプットする前に燃え尽きて
 しまいそうな時に読む精神論
• TDDはレッド、グリーン、リファクタリング
  のリズムが⼤事。だけど、リズムが壊れたか
  らといって自分の能⼒が低いわけじゃないと
  開き直れるかどうか。
• レッドの場合、自分が書いたコードに問題が
  ある場合が実際に多い。つまり、現実と向き
  合えるかどうかが問われる。
• 問題を先延ばしにしない強い心を。
• 焦らないでOK。初めは時間がかかるものと
  心得て、みんなで強い意志で取り組む。
最近の僕のTDD使い方まとめ
• レガシーコードと泥臭く戦う。
 – MVCならModelから少しずつ
 – Contorllerに残ってるコードはテストコードを書きながらリファクタリ
   ングしていく(=仕様化テストの導入)

• 自分の経験不足を言い訳にしない
 – テストコードを書くと生産性が落ちるのは自分のせい
 – 書くテストコードの量は、1パターンでも書くと全然違う
 – TDDで戦うところとそうでないところ、割り切りも⼤事

• 一人で戦わない。仲間と戦う。
 – 孤独との戦いもある
 – レッド、グリーン、リファクタリングのリズムが崩れてもファイティ
   ングポーズをとれるか。
 – つらかったら話を聞いてもらうだけでも違う
[付録] 読んでおくべきTDD関連の
        ソース
• 三周遅れのXP
 – http://www.slideshare.net/yoshiori/xp-
   3242327
• 読んでおくべきテスト関係のTL
 – http://togetter.com/li/5878
 – http://togetter.com/li/6759
 – http://togetter.com/li/6923

More Related Content

What's hot

例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪Takuto Wada
 
やはりお前らのMVCは間違っている
やはりお前らのMVCは間違っているやはりお前らのMVCは間違っている
やはりお前らのMVCは間違っているKoichi Tanaka
 
オーバーエンジニアリングって何? #devsumi #devsumiA
オーバーエンジニアリングって何? #devsumi #devsumiAオーバーエンジニアリングって何? #devsumi #devsumiA
オーバーエンジニアリングって何? #devsumi #devsumiAOre Product
 
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー「速」を落とさないコードレビュー
「速」を落とさないコードレビューTakafumi ONAKA
 
関数型・オブジェクト指向 宗教戦争に疲れたなたに送るGo言語入門
関数型・オブジェクト指向宗教戦争に疲れたなたに送るGo言語入門関数型・オブジェクト指向宗教戦争に疲れたなたに送るGo言語入門
関数型・オブジェクト指向 宗教戦争に疲れたなたに送るGo言語入門Tadahiro Ishisaka
 
O/Rマッパーによるトラブルを未然に防ぐ
O/Rマッパーによるトラブルを未然に防ぐO/Rマッパーによるトラブルを未然に防ぐ
O/Rマッパーによるトラブルを未然に防ぐkwatch
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)mosa siru
 
ソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビューソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビューMoriharu Ohzu
 
どこに何を書くのか?
どこに何を書くのか?どこに何を書くのか?
どこに何を書くのか?pospome
 
日本語テストメソッドについて
日本語テストメソッドについて日本語テストメソッドについて
日本語テストメソッドについてkumake
 
プログラムの処方箋~健康なコードと病んだコード
プログラムの処方箋~健康なコードと病んだコードプログラムの処方箋~健康なコードと病んだコード
プログラムの処方箋~健康なコードと病んだコードShigenori Sagawa
 
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェースモジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェースHajime Yanagawa
 
Discordから バーチャルオフィス「Teamflow」 に乗り換えてみた 雑談を生む工夫
Discordから バーチャルオフィス「Teamflow」 に乗り換えてみた 雑談を生む工夫Discordから バーチャルオフィス「Teamflow」 に乗り換えてみた 雑談を生む工夫
Discordから バーチャルオフィス「Teamflow」 に乗り換えてみた 雑談を生む工夫Koichiro Matsuoka
 
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話Yusuke Hisatsu
 
Redmineとgitの 連携利用事例
Redmineとgitの 連携利用事例Redmineとgitの 連携利用事例
Redmineとgitの 連携利用事例Tomohisa Kusukawa
 
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方増田 亨
 
MySQLで論理削除と正しく付き合う方法
MySQLで論理削除と正しく付き合う方法MySQLで論理削除と正しく付き合う方法
MySQLで論理削除と正しく付き合う方法yoku0825
 
TDD のこころ @ OSH2014
TDD のこころ @ OSH2014TDD のこころ @ OSH2014
TDD のこころ @ OSH2014Takuto Wada
 

What's hot (20)

例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪
 
やはりお前らのMVCは間違っている
やはりお前らのMVCは間違っているやはりお前らのMVCは間違っている
やはりお前らのMVCは間違っている
 
オーバーエンジニアリングって何? #devsumi #devsumiA
オーバーエンジニアリングって何? #devsumi #devsumiAオーバーエンジニアリングって何? #devsumi #devsumiA
オーバーエンジニアリングって何? #devsumi #devsumiA
 
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
 
RSpecしぐさ
RSpecしぐさRSpecしぐさ
RSpecしぐさ
 
関数型・オブジェクト指向 宗教戦争に疲れたなたに送るGo言語入門
関数型・オブジェクト指向宗教戦争に疲れたなたに送るGo言語入門関数型・オブジェクト指向宗教戦争に疲れたなたに送るGo言語入門
関数型・オブジェクト指向 宗教戦争に疲れたなたに送るGo言語入門
 
O/Rマッパーによるトラブルを未然に防ぐ
O/Rマッパーによるトラブルを未然に防ぐO/Rマッパーによるトラブルを未然に防ぐ
O/Rマッパーによるトラブルを未然に防ぐ
 
Oss貢献超入門
Oss貢献超入門Oss貢献超入門
Oss貢献超入門
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
 
ソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビューソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビュー
 
どこに何を書くのか?
どこに何を書くのか?どこに何を書くのか?
どこに何を書くのか?
 
日本語テストメソッドについて
日本語テストメソッドについて日本語テストメソッドについて
日本語テストメソッドについて
 
プログラムの処方箋~健康なコードと病んだコード
プログラムの処方箋~健康なコードと病んだコードプログラムの処方箋~健康なコードと病んだコード
プログラムの処方箋~健康なコードと病んだコード
 
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェースモジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
 
Discordから バーチャルオフィス「Teamflow」 に乗り換えてみた 雑談を生む工夫
Discordから バーチャルオフィス「Teamflow」 に乗り換えてみた 雑談を生む工夫Discordから バーチャルオフィス「Teamflow」 に乗り換えてみた 雑談を生む工夫
Discordから バーチャルオフィス「Teamflow」 に乗り換えてみた 雑談を生む工夫
 
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
 
Redmineとgitの 連携利用事例
Redmineとgitの 連携利用事例Redmineとgitの 連携利用事例
Redmineとgitの 連携利用事例
 
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
 
MySQLで論理削除と正しく付き合う方法
MySQLで論理削除と正しく付き合う方法MySQLで論理削除と正しく付き合う方法
MySQLで論理削除と正しく付き合う方法
 
TDD のこころ @ OSH2014
TDD のこころ @ OSH2014TDD のこころ @ OSH2014
TDD のこころ @ OSH2014
 

Viewers also liked

ユニットテストの保守性を作りこむ, xpjugkansai2011
ユニットテストの保守性を作りこむ, xpjugkansai2011ユニットテストの保守性を作りこむ, xpjugkansai2011
ユニットテストの保守性を作りこむ, xpjugkansai2011H Iseri
 
アジャイル開発とTDDを半年間実践してみた顛末と、これから
アジャイル開発とTDDを半年間実践してみた顛末と、これからアジャイル開発とTDDを半年間実践してみた顛末と、これから
アジャイル開発とTDDを半年間実践してみた顛末と、これからKei Sawada
 
Tokyor14 - R言語でユニットテスト
Tokyor14 - R言語でユニットテストTokyor14 - R言語でユニットテスト
Tokyor14 - R言語でユニットテストYohei Sato
 
テスト駆動開発入門
テスト駆動開発入門テスト駆動開発入門
テスト駆動開発入門Shuji Watanabe
 
TDDBC Fukuoka Day1
TDDBC Fukuoka Day1TDDBC Fukuoka Day1
TDDBC Fukuoka Day1Takuto Wada
 
AWS Black Belt Tech シリーズ 2015 - AWS Data Pipeline
AWS Black Belt Tech シリーズ 2015 - AWS Data PipelineAWS Black Belt Tech シリーズ 2015 - AWS Data Pipeline
AWS Black Belt Tech シリーズ 2015 - AWS Data PipelineAmazon Web Services Japan
 

Viewers also liked (6)

ユニットテストの保守性を作りこむ, xpjugkansai2011
ユニットテストの保守性を作りこむ, xpjugkansai2011ユニットテストの保守性を作りこむ, xpjugkansai2011
ユニットテストの保守性を作りこむ, xpjugkansai2011
 
アジャイル開発とTDDを半年間実践してみた顛末と、これから
アジャイル開発とTDDを半年間実践してみた顛末と、これからアジャイル開発とTDDを半年間実践してみた顛末と、これから
アジャイル開発とTDDを半年間実践してみた顛末と、これから
 
Tokyor14 - R言語でユニットテスト
Tokyor14 - R言語でユニットテストTokyor14 - R言語でユニットテスト
Tokyor14 - R言語でユニットテスト
 
テスト駆動開発入門
テスト駆動開発入門テスト駆動開発入門
テスト駆動開発入門
 
TDDBC Fukuoka Day1
TDDBC Fukuoka Day1TDDBC Fukuoka Day1
TDDBC Fukuoka Day1
 
AWS Black Belt Tech シリーズ 2015 - AWS Data Pipeline
AWS Black Belt Tech シリーズ 2015 - AWS Data PipelineAWS Black Belt Tech シリーズ 2015 - AWS Data Pipeline
AWS Black Belt Tech シリーズ 2015 - AWS Data Pipeline
 

Similar to TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ

Grand Strategy For Presentation
Grand Strategy For PresentationGrand Strategy For Presentation
Grand Strategy For Presentationbash0C7
 
リーダブルコードを読んだ後
リーダブルコードを読んだ後リーダブルコードを読んだ後
リーダブルコードを読んだ後Kouhei Sutou
 
Tddのすゝめ
TddのすゝめTddのすゝめ
Tddのすゝめ将 高野
 
リーダブルコード 1.0'
リーダブルコード 1.0'リーダブルコード 1.0'
リーダブルコード 1.0'Yamamura Takashi
 
DDDをScrumで廻す あるいは ScrumをDDDで廻す
DDDをScrumで廻す あるいは ScrumをDDDで廻す DDDをScrumで廻す あるいは ScrumをDDDで廻す
DDDをScrumで廻す あるいは ScrumをDDDで廻す Kiro Harada
 
TDD を自分の道具にしよう
TDD を自分の道具にしようTDD を自分の道具にしよう
TDD を自分の道具にしようYuji Okazawa
 
マジカルsvnとキュアgit
マジカルsvnとキュアgitマジカルsvnとキュアgit
マジカルsvnとキュアgitTakafumi ONAKA
 
nseg第5回勉強会
nseg第5回勉強会nseg第5回勉強会
nseg第5回勉強会ko ty
 
TDDはじめる前に
TDDはじめる前にTDDはじめる前に
TDDはじめる前にYasui Tsutomu
 
作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていくRyo Mitoma
 
KDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フローKDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フローques_staff
 
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~Tomomi Kajita
 
仕様七変化
仕様七変化仕様七変化
仕様七変化galluda
 
とある Perl Monger の働き方
とある Perl Monger の働き方とある Perl Monger の働き方
とある Perl Monger の働き方Yusuke Wada
 
TypeScript 型定義ファイルのある開発 TypeScript勉強会 VSハッカソン倶楽部
TypeScript 型定義ファイルのある開発 TypeScript勉強会 VSハッカソン倶楽部TypeScript 型定義ファイルのある開発 TypeScript勉強会 VSハッカソン倶楽部
TypeScript 型定義ファイルのある開発 TypeScript勉強会 VSハッカソン倶楽部Masahiro Wakame
 

Similar to TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ (20)

Sue445 Style TDD #atest_hack
Sue445 Style TDD #atest_hackSue445 Style TDD #atest_hack
Sue445 Style TDD #atest_hack
 
Grand Strategy For Presentation
Grand Strategy For PresentationGrand Strategy For Presentation
Grand Strategy For Presentation
 
リーダブルコードを読んだ後
リーダブルコードを読んだ後リーダブルコードを読んだ後
リーダブルコードを読んだ後
 
Tddのすゝめ
TddのすゝめTddのすゝめ
Tddのすゝめ
 
TDDを研ぎ究める
TDDを研ぎ究めるTDDを研ぎ究める
TDDを研ぎ究める
 
リーダブルコード 1.0'
リーダブルコード 1.0'リーダブルコード 1.0'
リーダブルコード 1.0'
 
DDDをScrumで廻す あるいは ScrumをDDDで廻す
DDDをScrumで廻す あるいは ScrumをDDDで廻す DDDをScrumで廻す あるいは ScrumをDDDで廻す
DDDをScrumで廻す あるいは ScrumをDDDで廻す
 
TDD を自分の道具にしよう
TDD を自分の道具にしようTDD を自分の道具にしよう
TDD を自分の道具にしよう
 
Node js 入門
Node js 入門Node js 入門
Node js 入門
 
マジカルsvnとキュアgit
マジカルsvnとキュアgitマジカルsvnとキュアgit
マジカルsvnとキュアgit
 
nseg第5回勉強会
nseg第5回勉強会nseg第5回勉強会
nseg第5回勉強会
 
TDDはじめる前に
TDDはじめる前にTDDはじめる前に
TDDはじめる前に
 
作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく
 
KDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フローKDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フロー
 
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
 
仕様七変化
仕様七変化仕様七変化
仕様七変化
 
とある Perl Monger の働き方
とある Perl Monger の働き方とある Perl Monger の働き方
とある Perl Monger の働き方
 
資料
資料資料
資料
 
TypeScript 型定義ファイルのある開発 TypeScript勉強会 VSハッカソン倶楽部
TypeScript 型定義ファイルのある開発 TypeScript勉強会 VSハッカソン倶楽部TypeScript 型定義ファイルのある開発 TypeScript勉強会 VSハッカソン倶楽部
TypeScript 型定義ファイルのある開発 TypeScript勉強会 VSハッカソン倶楽部
 
java-ja TDD 2nd
java-ja TDD 2ndjava-ja TDD 2nd
java-ja TDD 2nd
 

Recently uploaded

「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-LoopへTetsuya Nihonmatsu
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor arts yokohama
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdfAyachika Kitazaki
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~arts yokohama
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfMatsushita Laboratory
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦Sadao Tokuyama
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見Shumpei Kishi
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)ssuser539845
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法ssuser370dd7
 

Recently uploaded (12)

2024 03 CTEA
2024 03 CTEA2024 03 CTEA
2024 03 CTEA
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
 
What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
 
2024 04 minnanoito
2024 04 minnanoito2024 04 minnanoito
2024 04 minnanoito
 

TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ