TDDBC大阪1.0

対象

　飲み物自動販売機

課題

ステップ１　お金の入力と表示

• 千円札と硬貨を投入することができる。
  • 入力は複数回できる。
• 投入操作は釣り銭を出力する。
  • 想定内のもの(10円、50円、100円、500円、1000円)が投入された場合、投入金額として蓄える
  • 想定外のもの（硬貨：１円玉、５円玉。お札：千円札以外のお札）が投入された場合、そのまま釣り銭として払い戻す (APIレベルでは例外でも良い)
• 払い戻しボタン操作を行うと、投入金額を釣り銭として出力し、投入金額を０にする。
• 現在投入されている合計金額を取得できる。

ステップ２　ジュースの管理

• 値段と名前の属性からなるジュースを１種類格納できる。
• 初期状態で、コーラ（値段:120円、名前”コーラ”）を５本格納している。
• 格納されているジュースの情報（値段と名前と在庫）を取得できる。

ステップ３　購入

• 在庫状況と投入金額を元に、コーラが購入できるかどうかを取得できる。
• 購入できるまでお金を投入して購入操作をすると、１個ずつジュースを出力する。
  • 購入操作はジュースと釣り銭を出力する。
  • 購入操作をして購入できたら、ジュースの在庫を減らし、売り上げ金額を増やす。
• 在庫切れのジュースを購入した場合、何もしない。ジュースは出力しない。

ステップ３では釣銭切れを考慮しない。

ステップ４　釣り銭と売り上げ管理

• 釣り銭用ストックを持つ事ができる。釣り銭用ストックの初期状態は千円札5枚、硬貨各10枚。
  • なお釣り銭用ストックと売り上げは別管理。売り上げのお金を釣り銭用ストックとして流用する事はない。
• 購入操作をして釣り銭が発生した場合、その釣り銭を出力する。
  • 釣り銭を返した分、釣り銭用ストックを減らす。
• 購入操作を行った際に、釣り銭用ストックが足りない場合、何もしない。
• 売り上げと釣り銭用ストックの状況を取得できる。

ステップ５　機能拡張

• ジュースを3種類管理できるようにする。
  • 在庫にレッドブル（値段:200円、名前”レッドブル”）5本を追加する。
  • 在庫に水（値段:100円、名前”水”）5本を追加する。
• お金を投入した際は、購入可能なドリンクのリストを出力する
• 売上金を釣り銭にまわす事ができる。
  • 売上金の出力では、釣り銭と売上金の合算を出力する。

以下応用課題

ステップ６　更なる機能拡張

• 「ランダム」ドリンクを在庫に加える。
  • 「ランダム」ドリンクは、コーラ、ダイエットコーラ（値段:120円、名前”ダイエットコーラ”）、お茶（値段:120円、名前”お茶”）がランダムに並べられている。購入するたびに、ランダムにならべたドリンクを順々に出力する。
• ジュース購入後、5%の確率で「あたり」イベントを発生させる。
  • 「あたり」イベントが発生したら同じジュースを２つ出力する。
  • なお在庫がない場合は「あたり」イベントは発生させない。

ステップ７　更なる更なる機能拡張

• 在庫のジュースの賞味期限（年月日）を個々のジュース単位で保持・取得できる。
• 現在日時が購入対象のジュースの興味期限を超えていた場合、ジュースを購入不能にする。

インターフェース

　状態を持つ対話的なインターフェース。それぞれのステップで使う統一インターフェースではなく、全体概要を示す参考情報です。

• 【入力】
  • お金
  • 払い戻しボタン
• 【状態】
  • お金（釣り銭用ストックと売上）
  • ジュース
• 【出力】
  • 投入金額
  • 売り上げ金額
  • 釣り銭
  • ジュース一覧
  • 購入可能なジュース一覧
  • ジュース

Keep

• 会場
• 楽天会場
• 会場、快適でした #ステマじゃなく。

• Groovy!
• Spockス・テ・キv
• Groovyに興味が沸いた
• Groovyが楽しそうだった。書きやすい＆見やすい
• 新しいライブラリを知った（Spock）

• 昼食：弁当

• ペアプロをちゃんと初めてできた
• ペアプロ、TDD
• ペアプロ、TDDが経験出来たということがよかった。これまで経験した事がなかったので。
• ペアプロ初体験
• ペアプロを初めて行って、その楽しさを知った
• ペアプロについて体験する事ができた。
• ペアプロでテストの抜けに気づけた！
• 今回、ペアプロ初体験だったのですが、自分では中々気付けない事、気付けても遅くなってしまう事をその場で指摘してもらえるかはイイデスネ！
• 久しぶりにペアプロががっつりできて良かった
• TDDを具体的に体験出来た
• TDDの実際の使い方がよく理解出来た！
• TDDでたくさん失敗出来た（テストの粒度とか）
• TDDによって「不安をなくすため、テストをする」ということが理解出来た
• TDDの進め方がわかった
• うわさに聞いていたTDDを体感できてよかった
• 自分が行っていたTDDが間違っていた事が判った。（テスト項目が細かすぎた）
• 楽しかった。刺激になった。（ペアプロはアイスブレークに使えるのかも…）
• 他の人の書いたコードを（レビューなどで）見ることができた
• 新しい実装の仕方が判って良かった
• 進行がやさしい
• 発想が根っこから変わった
• テストを書いている時に思っていた疑問点が解消されたり、ヒントが貰えたりして、良かった。
• 楽しかった
• テストコードを実際に書いてみるのは初めてでしたが、とにかく粒度を下げてちょっとずつ解決していくのは良い経験になりました。
• 何をテストすべきなのか分かった
• コードとテストで相互にテストしていく。（単純な実装でテストの正しさを確認）

• 経験者のテストコードの書き方、作法を見ることができた
• 仕様にあまり迷わないよう事前に決めた
• C言語でのTDDは可能だと分かった
• テストの組み立て型がちょっと分かった
• 仮実装をやってみたところ、テストコードのバグを見つけることができた。100%自信がある時でもやってみるべきだと感じた
• TDD自体が良かった
• 盛り上がっていて会場の雰囲気がとても良かった
• セッションと手を動かすバランスが良かった
• 吉岡さん、和田さんとお話しできた

• 上役を説得するのに良い情報を仕入れることができた
• TAの方がたくさんいてくれたのでワークショップの時はとても良かった
• TAの人数が多かったので、質問しやすかった
• TAの方に沢山アドバイスやテクをいただきました。
• TAの皆様が話しやすく、気さくで良かった。
• 色々な人の体験談(生の声)が聞けた
• JASSTにも興味が出た
• レガシーコード改善ガイドを読みたくなった
• レガシーコードに対する方法は使えそうで良い
• テストを書くことで、コードを使う人のことを考えられた
• 色々な人の話が聞けた
• なんとなくTDDをやっていたが、今回のBCで理解が深まった
• 他の言語での実装を見て勉強になった(テストメソッドの作り方、メソッドの作り方)

• 事前に環境をインストールしていたこと
• シンプルな実装を心がけたら、キレイに書けた。
• ペアプロいいね。聞ける人がいるのは安心する。
• 会社や家ではなかなかできないペアプロができる環境を提供して頂いたこと。
• vimに詳しくなった！
• 社内で広める自信がついた（Groovyじゃないです）
• TDDについて考えたいところが色々と話しをして考えることができた
• ペアプログラミングをじっくり経験することができてよかった。業務ではなかなか経験できないので。
• C++忘却していたけどペアプロで何とかなった。
• ペアプロをすることでレビューをするまえに改善されると思った。
• なじみの薄い言語やフレームワークを見ることができた
• assertThatをおしえてもらった
• 自分の知らない言語のテストとか見れて参考になった
• 貴重なペアプロタイミングの機会
• ペアプログラミングが勉強になった。いつも一人で開発してるのでそうだんしながらできてよかった。
• Red→Greenをゲーム感覚で楽しめることがわかった
• ネット（無線）あるのべんり！楽天は神 #ステマ
• TDDBCそのもの
• 同じペアでじっくり考えられるのは良かった

Problem

• 弁当のおかずのバリエーション
• おしりが痛い
• もっと交代した方が良かったかも
• テストの習熟度が違う人とペアプロした方が良いかも
• コーディングする人が偏ってしまった
• 書き始めると交代する機会が掴みにくい
• ドライバー/ナビゲーターの入れ替えがなく消耗した

• FizzBuzzについてきっちりした説明がなかった
• ペアプロはどのように進めていったら良かったのか、分からなかった
• デモTDDはしこみでよいと思う
• 開場時刻のちょっと前にスタッフが行く
• 課題のディテールが分かりにくかった(相談する材料にはなった)
• ToDoをもっと明確に
• タイムテーブルを守る

• 途中で体力が尽きて集中力がなくなった
• 女性...
• しっかり睡眠をとらないと体力が…
• RSpec、Rubyの知識不足
• いす。尻いたい

• TDDを回すサイクルの大きさに迷いがあった
• リファクタリングにあまり時間を取れなかった
• テストメソッドの粒度が荒くいくつものassertを入れてしまった
• ビルド環境を整えていなかった
• 2日前の23時にIntelliJ IDEAの導入をすすめるTA
• 動作環境の基準が少しはあっても良かったと思う
• ツールの使い方をもう少し知っておけばWorkshopの時間が有効に使えたのに
• コードは管理の仕方を考えて、全て、全員に見える形になるともっと勉強になるのかなと
• テストを書くこと自体が目的となってしまった
• リファクタリングをしようと各関数の引数や戻り値を見直したが、テストを変えずに変更してしまったため目標点を途中で見失った
• リファクタリングで設計が変わるならテストを変えるべきだった
• 課題をこなすことに注力しすぎた
• ある程度慣れてきたところでテストの粒度を荒くしてみたが、それをパスするコードを書いているうちにあちこちに目がいってしまい寄り道してしまった。結果、1 サイクルがとても長くなってしまった
• 設計せずにコードを書いた。本当にうまく出来たか不安になった。ToDoリストをうまく使うべきだった？
• テストコードを書くのがやっぱり面倒に感じてしまう
• xUnit導入ガイドの案内とか、リンクが欲しい。あるいはチュートリアルとか
• 仕様変更辛かった
• 途中でペア変更があってもよかった
• 仕様変更の難しさを改めて実感した
• Java組がassertThatを使ってなかった
• コードレビューはもう少し深くやっても良かったのではないか？コード、テストの問題点・改善点がもう少しあっても良かったと思う

Try

• クッションを持ってくる
• Ustまたは録画
• 事前におすすめのテスト実行環境を公開する
• 泊まりありのブートキャンプも参加してみたい
• 1時間くらいで交代を促す
• デモペアプロの時、「いま何をやっているフェーズか(Red/Green/Refactoringなど)」の掲示があると、参加者に分かりやすい
• 今度の開発でTDDを提案してみる

• ゴミ出しオペレーション
• TA静かに
• 飲み物(紙コップなど)のオペレーション
• お題に対して、TAはこういう風に解いたという紹介が最後にあるとよかった
• Q & Aの時間を増やして全体共有の場をもっととると面白いかも
• もっとみんなの体験談、苦労話を聞いてみたかった
• 今回のような入門と、業務への導入とのギャップ(DB周りとか)が大きく感じるので、そこを埋める学習法の紹介
• 人数ごとの言語分布。人がいるならやってみたい言語がある
• TDDでのテストコードとプロダクトコードの環境の分け方

• もう少しペース配分を考えたい
• 実装は大きなディスプレイでやりたい
• Jenkins、SATDD、Gradle、Mercurial
• RSpecとRubyの学習
• 十分な睡眠

• 言語固定でのTDDBC
• あらかじめ環境を整えておく
• 環境設定に手間取ったので事前に設定しておく
• PHPの開発環境を確立しないと
• サイクルを早くする
• ユニットテストの行える状態にしていなかったので次くる時は気をつけたい
• ちゃんとIDE使い慣れないと
• TDD関連書籍, サイトの写経
• Spockというものを知ったので使ってみたい
• ある程度踏み込んだ踏み込んだデータモデル/ドメインモデルを提示する
• ほかのチームのソースがもっと簡単に見れるといいな
• githubで標準環境を整えておく
• テストそのものをきれいに書けるようにする
• 参加者の横の連絡・交流
• フレームワークのチュートリアル
• Extreme Fish Bowlやりたい
• 疲れ果てたのでちょっと休憩をする
• F#に冒険する勇気がなかった。次こそは…
• 次回は教える側になれるように、今後TDDを実践したい
• ソフトウェアテスト技法の本を読む
• エディタの使い方まで教えてもらっていたので、次までには使えるようになっておきたい
• TDDを持ち帰って社内にその文化を根付かせたい。まずは自分から！