TDDBC大阪1.0 - udon's blog

行ってみました。

TDD自体はちょこまかゲリラ的にやってみたりでしたが、たいてい自分一人でやるだけでした。

後はまぁ、ちゃんと本も読んでねぇとか、結局プロダクトコードと一緒に書いてるだけとか、まぁそんなナンチャッテTDDばかり。でもってTDDBCも初参加でした。

一応言語の希望が事前にあって、「C」とだけ言っておきました。

# C++はよくわからんし、rubyはちょこっと趣味程度やし。。JAVA？なにそれと。

◯講演関係覚書

やっぱりそうですね。実際に思い描いた（設計した）APIやらは、使ってみないと扱いやすさはわからない。

そういえばAPI自体のマニュアルは充実してるけど「実際どう使えばいいの？(呼ぶ順番やシーンとか)」がさっぱりわからなかったMSDNって、最近良くなってるんでしょうかね？（私が見てたのはWindows APIでしたが）

「テストコードにバグがあったら？」に対する解。プロダクトコードよりも前にテストを書いたりするのもこの辺の狙いがあるとか。

後は「レビュー」も入れて欲しかった、ですかね。

「バージョン管理」「テスト」「自動化」

どこまでテストするの？の話。TDDで言うテストは、いわゆる「品質保証」なテストではなくて、「Developer's Test」であると。明らかに大丈夫な箇所や、自明なところまではテスト不要とね。

この辺の話を聞くといつも「強固にカバレッジ100%を求められて凄まじく炎上した」プロジェクトを思い出しますね。。。まぁ過去の話。

TDDのサイクル「Red」「Green」「Refactoring」につづく第四のステップとして「Destory」もあってはいいのではないか、という話。

「ここ危なくね？」なところをわざと狙ってテストをする、と。

なんだか探索的テストに近い匂いがしました。（あんまり詳しくはないですけど）

◯ワーク

課題はこちら

で、ペアを決めようって時にTAの細谷さんに勧められるままに隣の方とペアに。

@kyubunsさんでした。お初にお目にかかります！

ポジションペーパー使いながら自己紹介しましたがvimmerのようで。

vimいいですよね！

で、結局環境は「vim + GoogleTest + Terminal」になりました。

ちょっとキーバインドに躓いてしいまったのでコードはさっさとgithubにあげて共有っと。

前半後半３時間くらいやりました。

一応紙にToDoを書いてやって行きましたが、むずいなぁ。。。

◯ワークの感想と反省

いやー、結局足引っ張ってばっかだった気が。

てかあれ？いつの間にGoogle Testってmain()書かなくても良くなったん？最初から？？

ムチャぶりでレビュー対象にされてしまいましたが、まぁ何とか乗り切った、かな？

一応1.1/2.1の企画が進行している模様。

それまでにはcutterくらい使えるようになっておくか！