mokky14's IT diary

IT関係の仕事メモ、勉強会の感想など書いてます。

TDDBC仙台 4thに行ってきた

イベント テスト TDD 勉強会

昨年に続きTDDBC仙台に参加してきました。
@t_wadaさん、スタッフ、および参加者の皆さん、どうもありがとうございました。

当日のtogetter
TDDBC仙台 4th - Togetterまとめ

基調講演

@t_wadaさんによる基調講演。
講演資料は後日SlideShareにアップするとの事。

TDDの目標

f:id:mokky14:20141013042949p:plain
動作するキレイなコードがTDDの目標。
テストコードが存在することで、改善が可能になる。

ソフトウェア工学は予測性が低い。コードを書き始めることで初めて問題に気がつくことが多い。
なので、完璧な設計をしてから実装を始めるのではなく、とりあえず実装し、きれいなコードにするのはその後にする。TDDはその手助けをしてくれる。

TDDのサイクル

f:id:mokky14:20141013043644p:plain

  1. 目標を示すテストコードを書く
  2. テストを成功させるプロダクションコードを書く
  3. プロダクションコードをリファクタリングする

このサイクルが重要。
納期等の理由でリファクタリングされなくなる事があるけどちゃんとやりましょう。

テストコードのメンテナンスコストが高いと、「テストコード修正が大変だからプロダクションコードの改造はしない」という本末転倒な事になる。
なので、テストコードにもリファクタリングが必要。
プロダクションコードと同じく、テストコードもDRYにする。コピペしまくったりとかやってはいけない。

TDDを導入することで、実装時間は2割弱増えるが、その後の不具合検出数が減るため、トータルでの開発工数は減る。

TDDの対象範囲

f:id:mokky14:20141013042939p:plain
テストの目的は対象によって異なる。
TDDはDeveloper Testing。開発者の開発促進が目的。

f:id:mokky14:20141013184616p:plain
TDDの"T"はTestというよりCheckingに近い。(TDDはプロダクションコードが動作する事の確認でしかないため)
要件のテストとして、BDDという方法も出て来ているが、RSpecを使用したBDDとScenarioを使用したBDDの二派に別れているのが現状。

テストを動かすだけでは品質は上がらない。テストは品質を明確にするだけ。
品質を高めるのはリファクタリング。
体重計に乗っただけでは体重は減らないのと同じ。

なぜTDDをするか

f:id:mokky14:20141013043346p:plain
「動いているコードは触るな」とは今は言えない。
コードを触らなくても周り(OS、フレームワーク等)が変わっていく。直さざるを得ない。
何もしなければコードは腐っていく。

テストコードがあることで、コードへのフィードバックが即座に得られ、書いたコード、これから書くコードに自信が持てる。

TDDライブデモ

@135yshrさんと@nnasakiさんによるgo言語によるライブデモ。
go言語は全く知らなかったけど、@135yshrさんのIDE(Sublime text)の使いこなしに感心したり、「テストコード書くのにコピペは使わないようにしてる」の発言になるほどと思ったりしながら見させて頂きました。

昼飯

はらこめし。うま。
http://instagram.com/p/t_xzB5K_OL/

ペアプロ

昨年に続きJavaで参加。
Pythonやりたかったけどペア居なかった。。

課題と自分らのチームで実装したソース

TDD Boot Camp(TDDBC) - TDDBC仙台04/課題
実装ソース

感想KPT

Keep
  • IntelliJコーディング楽しい。
  • 「あれどうやるんだっけ？」と詰まった時に備えて「JUnit実践入門」持っていったのは正解だった。
  • GitHubでコード共有して演習進めたのは、お互いに自分のマシンが使用できて効率良かった。
  • コードレビューで、設計や改造について、色々なチームの意見が聞けたのが面白かった。
Problem
  • GitHubの使い方あんまり分かってなくてペアの方に世話になりっぱなしだった。
  • テストコードのリファクタリングやったとき、リファクタリング後のテストが動作するかの確認が雑だった。
  • 仕様追加時、作成済みテストコードの作り直しが多く発生した。実務で既存コードの修正量を抑える方法をもう少し考えた方がいいかも。
Try
  • ExpectedExceptionでExceptionの検証を行うテストが書ける事を教えてもらったので、後で機能確認しておく。
  • 残りの演習やってみる。

QAとか

和田さんへの質問と回答。

Q) 基調講演の中で、プロダクションコードとテストコードの比率が同じになるような例が出ていたが、テストコードはそんなに減らせるものなのか？
A) プロダクションコードとテストコードの比率が1:1になるようにリファクタリングし、プロダクションコードとテストコードの比率が1:1～1:2の範囲に収まるようにする。
この比率を超えるようならテストコードの見直しが必要。

Q) テストコードで、Mockは使うべきか、使わないべきか？
A) Mockは使う派と使わない派がいるが、@t_wadaさんはMock使わない派。
実物のコードが使えるなら、出来るだけ実物を使うようにしている。実物のコードを使うことで時間がかかるのは仕方ないと考えている。

最後に

テスト書きましょう。
f:id:mokky14:20141011110405p:plain