Slide 1
Slide 1 text
TDD
と 今まで
Gunma.web #52
@kanayannet
Slide 2
Slide 2 text
大前提
この資料は後ほど公開します
メモらなくてもOK
twitter
で賑やかし歓迎
#gunmaweb
Slide 3
Slide 3 text
アジェンダ
1.
どこで知った？
2.
その後どうした？
3.
仕事にどう繋げた？
4.
どうっだった？
5.
今はどうしてる？
6.
まとめ
Slide 4
Slide 4 text
どこで知った？
2010 RubyKaigi in Tsukuba
アジャイル開発 手法の一つとして知る
https://rubykaigi.org/2010/ja/events/23/
https://www.slideshare.net/nawoto/head-first-ordinary-
system-development
Slide 5
Slide 5 text
Rspec
BDD
という単語も知る
Slide 6
Slide 6 text
やってみないと
解らないね
Slide 7
Slide 7 text
感想
進めるとともに頭がスッキリしてきた感ある
とはいえ他の人どうやってるんだろ？
Slide 8
Slide 8 text
その後どうした？
Slide 9
Slide 9 text
TDDBC
TDD Boot Camp
という存在を知る
参加してみたかったが...tokyo
はあっという間に満員
隣の NSEG(
長野県)
がやってくださったので参加
TDDBC
長野0.1
Slide 10
Slide 10 text
どんな内容？
自販機のアルゴリズムの課題
Slide 11
Slide 11 text
千円札と硬貨を投入することができる（1
円玉5
円玉は使
えない。Exception
を投げる）
それ以外を投入された場合、Exception
を投げる
現在投入されている合計金額を算出できる
Slide 12
Slide 12 text
ID1
コーラ5
本120
円を在庫として保持する
お金を投入すると、現在購入できるID
を算出する
購入できるID
を指定して、ジュースを買うとコーラの在
庫が減る
現在の売上金額が算出される
現在の在庫数が算出される
在庫切れを考慮する
Slide 13
Slide 13 text
千円札5
枚、硬貨はそれぞれ10
枚保持する
ジュースが1
つ購入されるとお釣りとして、お金が減算
される
お釣りが足らなくて購入できない状態を考慮する
現在のお釣り用のお金が算出される
Slide 14
Slide 14 text
ID2
レッドブル 5
本 200
円 を追加
ID3
水 5
本 100
円を追加
Slide 15
Slide 15 text
前提が整った感
他の人がどうやってるか？見れた
Ruby
C#
PHP
JS
Slide 16
Slide 16 text
案外他の人も一緒
お互いどうやってるの？質問したり見させてもらったり
何かの技術、出始めあるある話
Slide 17
Slide 17 text
仕事にどう繋げた？
Slide 18
Slide 18 text
TDD
に向かない組織
(NSEG TDD
の発表より
)
プログラム設計,
実装,
単体テストの担当が別
単体テストでバグ検出率を求められる
Slide 19
Slide 19 text
幸いかな？
一人が任される環境
クロスチェックしてもらうことも可
ある意味ハードだがある意味やりやすい
Slide 20
Slide 20 text
いつやるか？
Slide 21
Slide 21 text
心構え
他社さん(
勉強会で出会った人たち)
も手探り感MAX
でや
ってるんだから
自分もこれでいんじゃない？
最早、パーフェクトを求めない
Slide 22
Slide 22 text
とりあえず、やってみる
Ruby
Rspec
Perl
prove
use Test::More
Slide 23
Slide 23 text
他の人がやらない時
目の前で見せる
どのくらい細かくテストケースを整えるのか？
どのくらい細かくライブラリ関数切るのか？
どのくらいのスピード感で進むのか？
Slide 24
Slide 24 text
どうだった？
Slide 25
Slide 25 text
最重要
どのくらいのスピード感で進むのか？
TDD
やってない人と比較して
Slide 26
Slide 26 text
やっぱ結果が出ないとね
やってる人がいい結果を出す
興味を持つキッカケに
特に同じチームだと顕著に出る
Slide 27
Slide 27 text
何をテストするか？
自覚している事が重要
何のために、どのテストをするのか？
意外と疎かにしがち
ここが整わないと...
Slide 28
Slide 28 text
間違ったゴールを
目指してしまう
Slide 29
Slide 29 text
あるある話
TDD =
自動テスト
TDD =
テストフレームワーク
Slide 30
Slide 30 text
違う
Slide 31
Slide 31 text
TDD
TDD =
テストを事前に書く
テストを事前に書く =
テスト内容を事前に決める
テストフレームワーク苦手なら debug
コードでもいいん
じゃない？
なれた後に テストフレームワークを使うでも
Slide 32
Slide 32 text
あるある話
2
テストを先に決めていたら実装するまで時間がかかるよ
遅くなるんじゃない？
Slide 33
Slide 33 text
そんな事はない
順番の問題なだけ
Slide 34
Slide 34 text
WHY?
Slide 35
Slide 35 text
最後に動作確認してもらうよね？
どんな案件でも一人で終わることはない
Slide 36
Slide 36 text
つまり
後にやるか？先にやるか？の違い
Slide 37
Slide 37 text
先にやる際の利点
テスト内容 =
要求内容 =
ゴール
これがハッキリ見えるの大きい
テスト内容の時点で依頼者・関係者(
非エンジニア)
に
確認できる
Slide 38
Slide 38 text
ライブラリ関数の粒
テストケースが整うと自然と決まってくる感ある
テスト時の役割ごとに関数切る事が基本
これって...DDD
の感覚に似てくるかも？
用語を決めて ->
関数名に繋がる ->
ユビキタス言語
業務で使う役割ごとに切ってコードに ->
ドメインオブ
ジェクト
Slide 39
Slide 39 text
結果
同じチーム内外で情報が共有される
同じものを見ながら進む事重要
考慮漏れを発見しやすくなる
Slide 40
Slide 40 text
今はどうしてる？
Slide 41
Slide 41 text
新入社員に広めてます
Slide 42
Slide 42 text
重要
指示ではなく体験してもらう
命令は意味がない
同じものを見れるようにする
「仕方ないTDD
やるか」は意味がない
Slide 43
Slide 43 text
感覚は
DEBUG?
「テスト」と名前を聞くと...
実行結果の精度を求めがちだが
実際の本質は違う
理解度の確認
画面に出力しながら...
Slide 44
Slide 44 text
重要
感覚の話をします。
いきなりパーフェクトな回答は求めない
理解度の確認します
質問によるチェックテスト
効果も話します
人間の脳の記憶のされ方について
反復練習の重要さ
Slide 45
Slide 45 text
まとめ
Slide 46
Slide 46 text
体感しないと価値が解りずらい
精度は求めない ->
やってみる事大事
精度よりも Debug ->
探索する感覚
理屈で理解するより反復練習(
手を動かす)
した方が理解
できるよ
正しいゴール =
正しいテストケース =
先に書けば？ =
TDD
Slide 47
Slide 47 text
ご清聴
ありがとう
ございました