Posterous theme by Cory Watilo

わんくま同盟 名古屋勉強会 TDDワークショップに参加してきましたとさ。

1/14(土) にわんくま名古屋勉強会のTDDワークショップに参加してきました。

TDDは去年11月のTDDBC福岡いらいですね。

 

ちなみに、TDDっていうのは、

プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き(これをテストファーストと言う)、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。(Wikipediaより抜粋)

 

biacさんから、TDDってこんな感じなのよっていうお話を簡単なFizzBuzzの実装をテストコードをかきながら説明していただきました。いつもはjavaのJUnitしか使ったことがなかったから .netのテスト環境見れたのは新鮮でした。(それよりも、biacさんが使ってたWindows8とVisualStudio11がスゲーかっこいい。デベロッパーズ版ですかね)

Img_0940

やっぱり一番気になるのは、テストのコスト。本当にTDDで効果があがるのか?ってところだけど、実例によると、実装工数は2割増えるが、バグは半分以下になる!
MicrosoftのVisual Studio 2008の開発にいたってはバグが1/10になったとか。(ほんまかいな)

 

じゃあ、実際の現場でTDDをやってるのかどうかってところは、実はやったり・やってなかったり。というのも、全てにおいてテストコードを書くことが有効かというとそうじゃなくて、やっぱりTDDに向いている/向いていないがある。

TDDやる:ロジック、MVVMのVMなど
TDDやらない:UI、間違えそうもない単純なsetter/getter、定数定義など

後々、テストの使い回しができて手動でやるよりもコストが掛からない場合にTDDをやる!ってこと。

 

仕事ではもちろんテストはやるんだけど、決まったテストのやり方や基準は無いから、いつもはプログラムを作り終わってから、必要なテストを手動でガッて確認するってことが多い。(もうそろそろそのやり方を卒業せねば。。。)

 

グループに別れてTDDをペアプログラミングしましたが、(時間にして1時間)案の定あまり進みませんでした。(しかも、別予定があったため途中退出・・・)やっぱりテストコード書くのが慣れてないから時間がかかる。もうこれは練習あるのみかな。

出来なかった課題は後でやってみてまた公開したいと思います。