読者です 読者をやめる 読者になる 読者になる

udon's blog

思いついたことを、思いついた時に。忘れないように。

TDDBC大阪1.0

 

行ってみました。

http://atnd.org/events/28762

 

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

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

 

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

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

 

◯講演関係覚書

  • 自分が最初のユーザになる

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

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

 

  • 実装-テスト間で互いにテストしあう

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

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

 

  • 三本柱

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

 

  • 不安をテストする

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

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

 

  • 第四:Destroy

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

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

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

 

◯ワーク

課題はこちら

http://devtesting.jp/tddbc/?TDDBC%E5%A4%A7%E9%98%AA

 

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

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

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

vimいいですよね!

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

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

https://github.com/datsuns/jihanki

 

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

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

◯ワークの感想と反省

  • C++力足りなすぎ
  • 課題を解くことに注力しすぎてリファクタを疎かに
  • 開発環境を整えるのに手間取った(boostとかgcc4.7とかいろいろ)
  • コミュニケーションは良かった
  • もう少し全体像をモデリングしておくべきだった?

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

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

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

 

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

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