TDDBC OSAKA1.0へ参加しました!


 

2012年6月2日 TDDBootCampへ参加しました。

和田さんのセッションから始まり、ワークショップでTDDを実践し、夜の懇親会は闇LTでとてもサイコーな1日をすごせました。

特にGroovyには魅了されました。前から気になっていたのですが、Spockの素晴らしさが目に見えて凄いと思いました。

GrailsとかGraidleとかGroovy関連はなんか熱いっす!! これはもう始めましょう。。

そしてグリーンバンドも手に入れました。

今日からグリーンな男を目指してがんばろっと

以下、メモをまとめます。
  • 和田卓人さんのセッション

ソフトウェア開発の3本柱(三脚椅子)

・バージョン管理

・テスティング

・自動化(自働化)

人間ができることをする(デプロイなどの同じ作業は機械が向いている)。

基本的に自動で動かし通知方法を ツイッター、IRC、スカイプなどを通して人間に伝える。

人間がPullすることをなくし、機械がPush出来るようにする。

※バージョン管理が基本 これはソフトウェア開発の前提条件。


Testとは

・Developer Testing(開発者 開発促進) <ーTDDBCの対象

・CustomerTesting(顧客 進捗確認)

・QATesting(品質保証担当者 品質保証)

 

TDDのサイクル

1.テストを書き

2.そのテストを実行して失敗させ(Red)

3.目的のコードを書き

4.1で書いたテストを成功させ(Green)

5.テストが通るままでリファクタリングを行う(Refactor)

6.1〜5を繰り返す

 

黄金の回転

小さくはじめる

red, green, refactor を回す

 

TDDの心構え

1つずつ 少しずつ(大きい問題を小さく分割すること)

複数を相手にしない。(ひとりずつ対処する) 複数のテストを同時には書かない

素早くまわす(自分が何をするかがぼやけている場合は素早く回せない。) <ーこれが難しい。。と思う

不安に思うことについてテストを書く!

テストは目的じゃなくて手段(不安の克服健康体の維持)

 

テスト駆動開発とは何か

「健康」

変化に対応するのは健康体のコード

変化に対応するのは健康体のチーム

 

テストと製品コードについて

テストコードが正しいことはどうやって確認する?

テストコードと製品コードのつなぎ部分を確認する(テストコードの正しさは製品コードで確かめる)

そのために仮実装を行う。(必ず通る定数などを返すなど)

三角測量??

仮実装で通った値とは違う値を入れて確認してみる

テストコード自体はゴールから書く

何もない状態からテストをはじめるには。。

今回の自販機の課題であれば、何もない状態から表示するということを行う。(何もない状態で0を表示する)

 

最近のテストフレームワークは入れ子(ネスト)でかける Junit (Enclosed)

http://blog.livedoor.jp/ryu22e/archives/cat_50184887.html

テスト駆動に慣れてくると細かい単位のテストばかりではなく、大きな意味で、テストの構造を考える。インターフェースに対するテストなどPrivateメソッドなどの見えない部分はテストする必要があるか? Publicメソッド経由でPrivateメソッドはテストできる。だからPrivateメソッドのテストは各必要はない。

 

  • 以下、感じたことやその他のメモ。。

バージョン管理はやっぱり大事というか、最低限のもの。。コードを書く前にこれと仲良くならないといけない!!

パラメータライズドテスト これが凄いね。てすとにパラメータを与えることが出来る。。

Groovyのspockは凄い。

複数のパラメータで同じ内容を確かめたい時に使う(エラーケースを確認するなど)

 

破壊的なTest(関さん)

未知のものを探しに行く

テストを書く(通すためにする) OR テストをする(壊してやる、不具合を探す)

TDDは動くようにする、綺麗にするという繰り返しのループ。破壊的なテストをすることでコードを強くする事ができる

 

 

  • 振り返り

フレームワーク(KPT)http://ameblo.jp/tetsu7s/entry-10358337824.html

Keep

Try

Probrem

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です