ひよっこ。

I want to…

Posts Tagged ‘TDD’

fxug@北陸in富山をやったよ。

Posted by hikaruworld : 2011 4月 24

ずいぶん間が空いてしまいましたが、
fxug@北陸in富山をやりました。

スピーカーしてくれたwacky,@itsuki_kosen,@shoito
参加してくれた皆さん、ありがとうございます。
次は6月に金沢ですので興味ある方は是非〜。

個人的には富山で初見の人に会えたのがうれしかった!

久々に話しましたが、相変わらずぐだぐだに。
もっと練習しないとなー。

という訳で、セッション内容を張っておきます。
今回はMockitoというFlexのモッキングフレームワークについて話しています。

Posted in program | タグ: , , , , | Leave a Comment »

QuickJUnitを設定して、まず第一にやることを3つ

Posted by hikaruworld : 2011 4月 7

QuickJUnitになれてくると激しく便利です。
ところで、かゆい所に手の届くプラグインですが、もうちょっと細かい設定もしています。

BetaサイトにあるExtension周りを導入

UpdateSiteに以下を指定して、http://quick-junit.sourceforge.jp/updates/beta/
以下の辺りのライブラリを導入します。ProcessCallとか、Mockito連携とか便利です。
。。。TestContextはまだ使えてないけどorz…

  • Quick JUnit process call Extension
  • Quick JUnit Template Extension
  • Quick JUnit Test Feature
  • Quick JUnit TestContext Feature(Experimental)
  • Quick JUnit Mockito Integration Plugin
  • Quick JUnit Plugin

設定の変更

なぜか、自環境だと、Ctrl+Shift+0でデバッグしてくれないという致命的な問題があるので、
キーバインドの設定を変えておきます。
1. 一般 -> キー
2. フィルターに0を設定
3. JUnitデバッグをCtrl+Shift+-に設定

テンプレートを拡張

Mockitoやhamcrestを利用しているので、staticインポートへ変更しておきます。
デフォルトの設定だと、hamcrest側のMatcherをJUnitに内蔵されているMatcherに食われてしまいますorz…

1. Java -> エディター -> テンプレートを選択
2. テンプレートからQを選択
3. 編集をクリックしてテンプレートを以下のように変更

@${testType:newType(org.junit.Test)}
public void ${testname}() throws Exception {
	${junit:importStatic('org.junit.Assert.*')} 
    ${hamcrest:importStatic('org.hamcrest.Matchers.*')}
	${mockIto:importStatic('org.mockito.Mockito.*')}${cursor} 
}

4. テンプレートからATを選択
5. 編集をクリックしてテンプレートを以下のように変更

${junit:importStatic('org.junit.Assert.*')}assertThat(${:localVar(java.lang.Object)}${cursor},${hamcrest:importStatic('org.hamcrest.Matchers.*')}is(${expected}));

おまけというか要望

Ctrl+9でテスティングペアがない場合にテストケースを作成してくれるのはとてもうれしいのですが、
Maven構成とかでやってるとsrc/mainじゃなくてsrc/testのソースフォルダを自動で指定してくれるとめちゃうれしいです(><)

以上です。

Posted in program | タグ: , , , | Leave a Comment »

Mockito-Flexを利用してFlexのTDD/BDD環境を構築する(その2)

Posted by hikaruworld : 2011 2月 16

前回の続きになります。

Mockito-Flexの使い方

Java版のMockitoとの差異

基本的にはJava版のMockitoとほぼ同じですが、メソッドなど異なる部分もあります。
Java版のMockitoでは振る舞いのエミュレートの部分では、
when().thenを利用していましたが、mockito-flexの場合は、
given().willを利用する事になります。BDDMockito側を実装しているようですね。

ちょっとつらいのは、現在のmockitoでは複数の振る舞いの定義が出来ていないため、
以下のようなmockを書いても

given(hoge.piyo()).willReturn(“a”);
given(hoge.piyo()).willReturn(“b”);
given(hoge.piyo()).willReturn(“c”);

実行すると、以下のようになってしまいます。

trace(hoge.piyo()) // “a”
trace(hoge.piyo()) // “a”
trace(hoge.piyo()) // “a”

これは、Mockit-flex側でもIssuesとして、
#17 Multiple called given(something).willReturn(something) always returns first setted value
があがっていますが、まだ対応がはいっていないようです。
一応Answerを利用したやり方はあるようですので後述します。

Java版と同様な部分としては、DSL的な記述が可能なように
org.mockito.integrations以下にメソッド群が切り出されています。
Flex版ではグローバルメソッドとして定義されており、
Javaのようなstaticインポートが不要なところは言語的に楽ですね。

なお、これらのメソッドは実際はorg.mockito.Mockitoの
フィールドを呼び出すようになっています。
実際の挙動を確認する場合は、Mockitoの中身を確認すると良いかと思います。

Mockitoによる実装

ここからmockitoによって提供されている機能を確認していきます。
その際テスト対象のクラスが必要になりますので、
以下のクラスを対象にテストを行います。

public class Main
{
    public function Main()
    {
    }
    public function say(name:String):String
    {
        return "Hi " + name;
    }
    public function say(name:String):String
    {
        return "Hi " + name;
    }
    public function sayObj(obj:Object):String
    {
        return "obj is " + name;
    }
    public function check(data:Data):String
    {
        return data.userId;
    }
}
public class Data
{
	public var userId:int;
	public function Data()
	{
	}
}

なお、前回の方法でtargetに格納されている事とします。

Mock化

任意のクラスをMock化して振る舞いを設定する場合の方法です。

givenによる振る舞いの設定

given()を利用する場合は、以下のように記述します。

given(mock化するメソッドとその引数).willReturn(戻り値)

givenの引数にはmock化するメソッド[Mock]対象と、エミュレートしたい引数を設定します。
この引数はmockitoが提供するメソッドを利用して柔軟に設定する事が可能です。
willReturnはgivenによって与えられた条件時に返す値を定義します。
willReturn以外にも、will,willThrowがあります(詳しくは後述)。

引数のmock化

given時に引数をmock化するためのメソッドを見ていきます。

any()

any()は引数にどんな値を与えられても良い事を表します
(当然引数で定義される型の範囲内でですが)。
なお、any()はnull値を許容しますので、値がnullの場合でもmockとして処理されます

/**
 * anyのテストケースを検証_NULLでない場合
 */
[Test]
public function any_is_not_null():void
{
	given(target.say(any())).willReturn("piyo");
	
	var result:String = target.say("abc");
	
	assertThat(result, isA("piyo"));
}
/**
 * anyのテストケースを検証_NULLの場合
 */
[Test]
public function any_is_null():void
{
	given(target.say(any())).willReturn("piyo");

	// nullの場合でもwillReturnの値が返される
	// ちなみにundefでも問題なし
	var result:String = target.say(null);
	
	assertThat(result, isA("piyo"));
}

anyOf(Class)

anyOfも引数にどんな値を与えられても良い事を表します。
anyOfの引数には、対象の型を指定します。
例えばStringの場合は、anyOf(String)のように引数の型を指定します。

/**
 * anyOfのテストケースを検証_NULLでない場合
 */
[Test]
public function anyOf_is_not_null():void
{
	given(target.say(anyOf(String))).willReturn("piyo");

	var result:String = target.say("abc");

	assertThat(result, isA("piyo"));
}

ただし、前述のany()と異なりnull値を許容しません。mock化したメソッドに対して、
nullを引数に呼ばれた場合はArgumentErrorがthrowされます。

ArgumentError: obj cannot be null

havingPropertyOf

havingPropertyOf(property, value)は引数の持つプロパティの値が一致する場合に、
実行することが可能です。

[Test]
public function havingPropertyOf_test():void
{
        // 引数に渡されたプロパティuserIdが12の場合だけmock処理を行うように設定
	given(target.check(havingPropertyOf("userId", 12))).willReturn(22);

	var data:Data = new Data();
	data.userId = 12;
        // この場合にはwillReturnで指定した22が結果としてかえる。
	var result:int = target.check(data);

	verify().that(target.check(data));
	assertThat(result, isA(22));
}

TODO 継承周りとか調査

isItNaN

これはNaNつまり非数である場合にのみMock処理を行うために利用されます

[Test]
public function isItNaN_test():void
{
	given(target.sayObj(isItNaN())).willReturn("NaN value");

	var result:String = target.sayObj(Number.NaN);

	assertThat(result, isA("NaN value"));
}

notNull

そのまんまですね。値がnullでない場合のみMockのエミュレーションが実行されます。

[Test]
public function notNull_test():void
{
	given(target.say(notNull())).willReturn("Value is Null");

	var result:String = target.say("hoge");

	assertThat(result, isA("Value is Null"));
}

と、今回はこの辺で。
次回はverify周りに付いて書きます。

Posted in program | タグ: , , , , | Leave a Comment »

Mockito-Flexを利用してFlexのTDD/BDD環境を構築する(その1)

Posted by hikaruworld : 2011 2月 14

FlexでもユニットテストやMockライブラリが充実し、ずいぶんテストがしやすくなっています。
そこで、FlexでTDD/BDD環境の構築をしてみます。
なお、環境は以下のように構築しています

IDE FlashBuilderBurittoPreview
TestingFramework FlexUnit4 / Hamcrest-as / Mockito-Flex

Mockito-FlexはMock処理を簡単に行うためのフレームワークです。
内部的な実装はASMockに依存していますが、Mockitoを利用することで
ASMockのRecord->Replayの処理を省いて簡単にMockが作れるようになります(なるはず…)。

ライブラリの入手

必要な物を一通りダウンロードしてlibs以下においてパスを通します。

mockito-flex

今回の話題となるMockito-Flexです。
ここから現在の最新版1.4M5をダウンロードします。

FlexUnit4

FlashBuilder4にもFlexUnit4は同梱されているのですが、
ちょっと古いらしくRuleの実装がはいっていないバージョンです。
mockito-flexを利用する際、[Rule]があると楽できるため、ここから最新を落としておきます。
ちなみにバージョンは、FlexUnit4.1RC2でした。

Hamcrest-AS3

どうせなのでHamcrestのバージョンも最新にしておきましょう。
Hamcrest-as3はgitHubのここにあります。現時点での最新のバージョンは1.1.3になります。

テストうんぬん前にまずやるべき事

mockitoは最新版はAPIドキュメントなどもないので、ソースをダウンロードしておきます。
ソースはswcに紐つけておきましょう。
(Referenced Libraries -> mockito.XXX.swc -> 右クリックしてプロパティ -> ソース添付 -> 編集)
あと忘れずに、ASDocを作っておきます(以下はコマンドラインから)。

$ pwd
mockito-flex/mockito/src
$ asdoc -source-path ./main/flex/ -doc-sources ./main/flex/ -library-path ../libs/

まだドキュメントが十分そろっていないようですし、分からなくなったらASDocとソースを見るのが解決に一番の近道です。

テストのやりかた

さて、本題です。
ここにmockitoをFlexUnit4で動かすやり方が書いてありますので手順に従ってやっていきます。

基本的なやり方

mockitoをFlexUnit4上で利用するには3つの方法があるようです。

方法1:従来のケース

従来の方法?では、テストクラスへの[RunWith]を利用してmock化を行います。

/**
 * クラス宣言時にFlexUnit4の[RunWith]を利用してMockitoClassRunnerを指定
 */
[RunWith("org.mockito.integrations.flexunit4.MockitoClassRunner")]
public class MainTest
{
  /** Mock化対象のクラスを定義 */
  [Mock(type="com.wordpress.prepro.Main")]
  public var target:Main;
  
  // Testコード...
}

方法2:新しい方法(インスタンス化の制御を自信で行わない)

この方法を利用した場合、[Rule]の機能を利用してMockのインスタンス化が制御されます。
そのため、MockitoRuleを[Rule]メタタグを付けて初期化しておく必要があります。
ただし、インスタンス化の制御を[Rule]に依存するため、RunWithの設定を必要としません。

なお前述しましたが、Ruleは現在FBに同梱されているFlexUnitには含まれていません
ライブラリの部分の手順に従って、事前に最新版に置き換えておく必要があります。

/** [RunWith]は不要 */
public class MainTest
{
  /**
   * [Rule]でMockitoRuleをインスタンス化
   */
  [Rule]
  public var mockitoRule:IMethodRule = new MockitoRule();

  /**
   * Mock化対象クラスの宣言
   * 必ず***public***である必要がある。
   */
  [Mock(type="com.wordpress.prepro.Main")]
  public var mockie:Main;
  
  // Testコード...
}

なお、Mock化したいクラスにコンストラクタ引数が存在する場合は、以下のように設定します。
こうする事で、Mainクラスに引数1がコンストラクタ引数として渡されます。

/**
 * typeでMock化したいクラスを指定
 * argsListでコンストラクタに渡す値をもつフィールドを指定します
 */
[Mock(type="com.wordpress.prepro.Main", argsList="args")]
public var target:Main;
/**
 * Mock化するクラスに渡す引数を配列形式で定義します。
 */
public var args:Array = [1];

※ただし、この方法はドキュメント上には見つかりませんでした。
テストコードで見つけたので、今後どうなるかは不明です。

方法3:新しい方法2(インスタンス化の制御を自力で制御する)

方法2ではテスト実行時にmockオブジェクトが初期化※0されますが、
この方法を用いるとmock()メソッドを利用してmockオブジェクトのインスタンス化を制御します。

/**
 * Mock化対象クラスの宣言
 */
[Mock(type="com.wordpress.prepro.Main")]
public class MainTest
{
  /**
   * [Rule]でMockitoRuleをインスタンス化
   */
  [Rule]
  public var mockitoRule:IMethodRule = new MockitoRule();

  public var target:Main;
  
  // テストコード
  [Test]
  public function test():void
  {
    // mock()でmock化
    this.target = mock(Main);
  }
}

この方法のメリットは好きなときにmock化を制御できること、
また、その際にコンストラクタ引数を任意に指定できる事だと思います。

/**
 * Constructs mock object
 * @param clazz a class of the mock object
 * @param name a name used in various output
 * @param constructorArgs constructor arguments required to create mock instance
 * @return a mocked object
 */
function mock(clazz:Class, name:String=null, constructorArgs:Array=null):*;

とあるように、第一引数にMock化したいクラス名、第二引数にエイリアス?、
第三引数にコンストラクタ引数を指定する事が出来ます。

方法2のフィールド指定によるMock化では、コンストラクタ引数をプロパティとして、
定義しておく必要がありますが、方法3では、テストメソッド内でMockを組み立てながら、
引数を考える事が出来ます。

なお、不適切な引数の状態でMock化を指定した場合、
初期化時に以下のエラーが発生してしまいます。

ArgumentError: Incorrect number of constructor arguments supplied.

※0具体的には[Test]の実行時単位で初期化されます。

設定を間違った場合(タイポや、privateフィールドにしていたetc)などはmockオブジェクトの初期化に失敗するため、
nullアクセスのエラーが以下のようにメッセージ出力されます。
今のFlashBuilderだとカスタムメタデータまでは補完してくれないので、タイポに気をつけましょう….

TypeError: Error #1009: Cannot access a property or method of a null object reference.

何だか長くなってしまったので次に続きます。
次は、実際にmockやverifyを利用して[Test]を実行していきます。

Posted in program | タグ: , , , , | Leave a Comment »

xDDについて考える3

Posted by hikaruworld : 2010 3月 27

これは、前回の続きになります。

多層的にxDDを実践する

自分が考えるxDDの連携とは以下のような感じです。

また、こういった風にxDDを実践することの大きなメリットは、
Inputに対して最終的なOutputを早期に返せることだと思います。
※ここでいうOutputは実装された成果物ではなく、要求を満たすテスト仕様のアウトラインのことです。

つまり、「こういう機能が欲しいんだ」というユーザ要望に対して、
「このような仕様で行きますよ」ではなく「この動作が問題なく通れば機能は問題ありませんね」
という方法を提示します。

個人的には、要求に対応するのは実装結果ではなくその要求を満たすテストと考えています(どっかの受け売り気がする)。
具体的な流れとしては以下のような感じです。

1.DDD

どう組み込むかはまだはっきり見えていないのでTODOです…

2.SDD

あるストーリ(機能要求)があったとして、まずはそれを満たすStoryテストを記述する。
このテストはペンディングで構いません。
ペンディングで構わない理由は、GUIのテストは非常に複雑になってしまうこと、
機能要求レベルではUIが確定していないため「実現したい目的」を詰めていきたい、といったことが背景です。
このStoryテストが問題ない場合に、要件に落し込み設計を行います(BDDへ)。

3.BDD

機能要求レベルで合意が取られ、要件に落とし込む段階で、振る舞いの挙動を記述します。
振る舞いレベルで必要なモジュールを作成し、クラス化していきます(TDDへ)。
外部APIとして公開するような機能であれば、SDDと同様にペンディングレベルで確認が必要でしょう。

4.TDD

BDDで考えられたクラスやメソッドレベルの実装をTDDで設計を行いながら実装を行います。
このときテスタビリティのみではなく、デバッカビリティを考慮します。
つまり、TDDをやっていれば、必然的にテストしやすいコードとしにくいコードはわかると思いますので、
そこをインスペクションによって担保できるかを検討する必要があります。

xDDの連携によって得られる恩恵とは

ここでも書かれていますが、テストによってソフトの品質を保証する場合は、
何を重要視するかによって、必ずトレードオフが発生します。

但し、今回のように駆動単位でどの象限を保障し、品質を担保するかを行っている場合、
それぞれのフィールドにおいてお互いに補正することが可能になります。
これは非常に大きなメリットですね。

よく現場で言われる「品質」というバズワードは、こういった様々な目的に応じた
品質の属性を把握して議論できないため、内容が発散してしまっているように感じます。
実際に現場で活用する場合は、相手がどの部分を注視しているかを把握しながら、
交渉をしていきたいものです。

# 聖戦の系譜の外伝でトラキア776というSFCのゲームがあるんですが、
# それの聖戦士の書というのをなぜか連想しました。

参考

最後に@AfterClass

まぁ、なんだかんだいいつつ、すべて実行するのは難しいものですとか。
あと、xDDと命名された駆動開発の手法の多くは、
目的によって意識されやすいように命名されたものに過ぎないのかな、と思いました。

* 4象限をxDDで考えた場合は、厳密に分けられるわけではない。
* 常に特定の品質属性が求められるわけではなく、いつどこにフォーカスを当てるかによって変わる。

以上です。

Posted in program | タグ: , , , , | Leave a Comment »

xDDについて考える2

Posted by hikaruworld : 2010 3月 27

このエントリは前回の続きです。

xDDの背景

では、なぜこのような多様な駆動開発が提唱されているのでしょうか。

ひとつの理由としては、いくらTDDのみ実践して問題ないことを保障しても、
前提部分で問題があった場合に、テスト自体が意味がなくなることが多々あるためだと思います。
「うまく設計できた、実装は終わった、テストは問題ない、但し顧客が求めている機能ではなかった」
というケースですね。

つまり、駆動する基準(求めているもの)がシステムを作る上で流動的に変化していくことを
把握し対応出来ていないため、アジャイル的な方法にあわせてより大きいレベルでの
駆動が求められているようになってきているのではないでしょうか。

「求めているもの」、つまり設計時に何を考慮しテスト時に何を保証したいかは
実践アジャイルテストに『テストの四象限』というものが定義されています(以下の図参照)。
この図はテストを整理するのにとても参考になります。

これはソフトウェアを構築するに当たって、どのような観点でテストを
行う必要があるかを4面性で分割したものです。

この4象限は、xDDのそれぞれの手法によって多角的に補足しているのではないかと思います。
逆説的に言えば、それぞれのxDD(駆動開発)はそれぞれのフィールドを
満たすための解決方法と考えることも出来るのではないでしょうか。

4象限によって保障されるもの

前述したように、この4象限を保証するために
それぞれ異なる手法が用いられます。

そうすることで、ことなるテスト品質の属性を担保することが出来るのではないかと、
考えるようになりました。
品質の属性はここがわかりやすいと思います。

では、具体的に領域別に用いられる手法や、保証される属性を考えていきたいと思います。

自動(単体テスト・コンポーネントテスト)

TDDによって設計、実装が行われる領域です。
TDDによって設計されたコードは、十分な設計や、利用者を考えたクラスの設計が行われるので、
柔軟性・保守性・試験性などが高いコードになると思います。

自動と手動(機能テストなど)

BDDによって設計される領域です。
基本的な振る舞い、前提条件の検証、イレギュラーケースの検証などが行われるため、
相互接続性、移植性、堅牢性などが注視されると思います。

手動(シナリオテストなど)

SDDによって設計、および評価が行われます。
ユーザニーズを満たしているかを中心とした受け入れテストなどに重点をおいてテストされるため、
主として、使用性が中心として設計されると思います。

ツール(性能テストなど)

その他のテストとは少し色合いが違いますが、
システム全体の構成などに関してはDDDの領域で設計・検証が行われると思います。
可用性、効率性、完全性、信頼性、などが検証事項の中心になるのではないかと思います。
※DDDに関しては自身なし。ただこのレベルじゃないと保証しても意味が無いかなと思います。

というわけで、妄想は次回に続きます。

以上です。

Posted in program | タグ: , , , , | Leave a Comment »

xDDについて考える(その1)

Posted by hikaruworld : 2010 3月 16

※このブログはデブサミ後のTwitterで話題になっていた時に下書きしていたものをそのままUPしています。
先日TDDBootCamp北陸に参加して少し考えたところもあるのですが、それは別エントリに。

最近xDD(???-driven development)という言葉が色々取り上げらています。

  • TDD(Test-driven development)
  • BDD(Behavior-driven development)
  • SDD(story-driven development)
  • DDD(Domain-driven development)

※ここでTiDD(Ticket-driven development)のような技法を含んでいないのは、ちょっと方向性が違うかなと思ったためです。

デブサミでも話題になったそうで、Twitter上でも色々議論が流れているようですが、
ちょっといま忙しくてほとんど読めていないので、xDDとユニットテストに関して
少し自分の脳みそを整理してみたいと思います。

その前に@BeforeClass

まず、それぞれの単語を「誰が」「何のために」を基準に以下のように定義しておきます。
これは、xDDという単語がバズワード的に使われているのが現状でもあり(TDDとかそうですよね)、
あらかじめ定義しておかないと話が進まないためですorz..(thanks!! @t_wada)

TDDとは

言わずとしれたテスト駆動開発の略で、特定のクラス/メソッドを作成する際に、
事前に仕様プログラムを書いて、仕様検討を行いながらテストを書く方法です。
「開発者自身」が「設計に漏れがないかを確認するため」に利用します。

ex) 共通クラスAの実装を行う場合にテストプログラムで仕様を検討しながら実装を行う。

BDDとは

「振る舞い駆動開発」の略称で、そのコンポーネントやAPIがどのような挙動をすべきかを
事前に定義して、その振る舞いを実装していく手法です。
「その他の開発者」が「その機能を利用する際にどういった動きを求めているか」
を確認する目的で利用します。

ex) 外部API、Hogeの振る舞いを定義してそれに合うように実装を行う

SDDとは

特定の機能要件、つまり「ストーリー」を定義し、それにあわせて実装を行う方法です。
RubyではATDDといわれているそうですね。
「顧客」が「どういった機能を求めているか」を明確化するために実装されます。

ex) 特定の機能要件で求められる動きを確認するために行う。

DDDとは

ドメイン駆動開発の意味で、アプリケーションのドメイン単位、
つまり業務領域を対象に設計を行う手法らしいです。

が、あまりこのあたりは正確に理解していないため、詳しくは触れませんorz…

自分の考えるxDDの相対関係

以上のように、いずれのケースおいても設計のためのテストとなっています。
SDD,DDD(場合によってはBDDも)はプログラムの読めないユーザと
xDDのOutputを用いてコミュニケーションを行う必要があるため、
自然言語で「」読めることが重要かと思います。

ちなみに、私はxDDによって生成されたテストコードから
品質保証用のユニットテストを生成することは構わないと思います。

ただし、このレベルでのユニットテスト生成のコストがどこまでペイできるかの問題になるかと思います。
先日雑談をしていたときに、頻度の低い部分はインスペクションによって担保すればよいと言う話題もありました。
この場合は、定量的なテストが行いづらいのが難点な気がします。

ただ、ユニットテストとインスペクションは対であるという話があって意味合いとしては理解できます。

次に続く。

Posted in program | タグ: , , , , | Leave a Comment »

TDD読書会#3+北陸エンジニアグループ2009振り返り会に行ってきたよ

Posted by hikaruworld : 2009 12月 14

と言うわけで、TDD読書会#3+北陸エンジニアグループ2009振り返り会に行ってきました。
って、あれ開発プロセス勉強会だったような気が…まぁいいか。

北陸エンジニアグループに関連する勉強会は今年はこれで最後になります。
なんだか色々あった気がしますが、そちらは年末に改めて振り返ってみます。

あと、最後に@yuuitiroさんに、毎度のことながらインフラ関係を感謝したく思います。
目立たないけど、一番大事な縁の下の力持ちだと思います。

さて本題。
今回はこじんまりした形式ではなく、講義形式でTDD読書会では初参加の方がたくさんいたので、
冒頭に15分ほどTDDの歴史byKanazawaProcessとして発表しました。
以下がスライドです。

で、以下は内容の一行感想
詳しくは、他のみなさんが書かれてるのでそちらに譲ります。

#1 @hikaruworld
自分なので、省略。
#2 @coelacanth
SSASなんて今日知ったっす。面白そうだなーと思ったけど、バージョンが古すぎる…
今後のバージョンアップに期待

#3 @kussy_y
やっぱりファシリテーションって面白いなーと思う。
こういうのを会社でやりたいよねと思いました。

#Ex 懇親会
第七安し!!。ひとり1500円程度で食べれるのは医大だ!!

おまけ。
最後に今回のTwitterのタイムラインを貼っておきます。

katzchang はじまた。 #hokueng でいいよね。 2009-12-12 12:17:14
mitukiii 始まってる。 #hokueng 2009-12-12 12:20:11
rch850 「テストファーストなひと」「……」 #hokueng [VtP] 2009-12-12 12:26:48
katzchang さて、くしださんをお迎えにいくので、12:40ころに一度でかけます。13:30ころには帰ってくると思います。進行とか、どなたかお願いします>< #hokueng 2009-12-12 12:27:22
shozzy 今日のタグはこれか #hokueng 2009-12-12 12:29:13
rch850 SSASで単体テスト。へんたいだー #hokueng [VtP] 2009-12-12 12:31:41
katzchang 最優先事項:他のメンバーが持つ全ての疑問を解決するよう、協力します。 #hokueng 2009-12-12 12:33:20
katzchang ということで、自分がわからないことは質問していく!他の人の質問にはみんな答えていく!で行きましょう! #hokueng 2009-12-12 12:34:02
hikaruworld お昼ごはん。 #hokueng 2009-12-12 12:36:35
shoito 時間が時間だからか、みんなメシ食ってる #hokueng 2009-12-12 12:37:40
rch850 SSASって言ってるけど、実際はECMAScriptのほうが近い? #hokueng [VtP] 2009-12-12 12:39:18
wtnabe 実は SSAS がなんだかよく分かってなかったり #hokueng 2009-12-12 12:40:31
katzchang ですね。ASとか。 RT @rch850: SSASって言ってるけど、実際はECMAScriptのほうが近い? #hokueng [VtP] 2009-12-12 12:41:20
shozzy おやつ持ってくればよかったな #hokueng 2009-12-12 12:41:37
rch850 ほー、FMSってSSAS使うんだ #hokueng [VtP] 2009-12-12 12:43:23
checkela Testの規約って、言語毎に微妙に違うよねえ… #hokueng 2009-12-12 12:44:51
wtnabe prototype.superclass ってどのバージョンから使えるのかな? #hokueng 2009-12-12 12:44:56
wtnabe ecmascript 的には smallCamelCase にするのがいいのかな? 好きじゃないけど。 #hokueng 2009-12-12 12:46:49
shozzy 開発を進めるための方法=TDD。品質保証のための方法ではない。 #hokueng 2009-12-12 12:47:34
wtnabe この辺は宗教戦争なので、使ってる言語で推奨されているデフォルトスタイルでいくのがいいはず。好きじゃないけど。 #hokueng 2009-12-12 12:47:55
shozzy 同じxUnitを使うので混同しがちだけどね。これがTDD勉強会での発見だったな。 #hokueng 2009-12-12 12:48:08
rch850 .@coelacanth の FMSUnit が力技過ぎるw #hokueng [VtP] 2009-12-12 12:48:56
rch850 SSAS での単体テストに JSUnit のコードがだいぶ流用できそうに見えるなー #hokueng [VtP] 2009-12-12 12:53:13
shozzy 「アジャイルソフトウェア開発の奥義」は6000円するそう #hokueng 2009-12-12 12:58:53
shozzy ドキュメントは最小限でいいよー っていうか、要件が明確なら、内部設計はいらない。発注側としては。 #hokueng 2009-12-12 13:03:37
rch850 「納品」って単語にそもそもなじみが無いんだよなー #hokueng [VtP] 2009-12-12 13:03:51
shozzy 詳細設計書にSQLまで書いてたことある。意味ないよねー #hokueng 2009-12-12 13:04:25
rch850 詳細設計書とかって、なんかおかしいことがあったとき用なのかしらね #hokueng [VtP] 2009-12-12 13:05:57
shoito wikiにストーリー書いて、レビュー、調整、テストコード書いて、開発やねぇ #hokueng 2009-12-12 13:10:48
itsuki_kosen アジェイルソフトウェア開発によるメリットと言うか,良いところは迅速かつ適応的ってのはわかるけど,実際に何か作ったり案件として請け負ったものを,アジェイルソフトウェア開発でやると,具体的にどう変わるのか.どう良くなったのかの実例が知りたいなぁ. #hokueng 2009-12-12 13:11:19
shozzy 「気持ちいい開発」 #hokueng 2009-12-12 13:11:24
shozzy 土曜出勤とかぶるとほんとへこむよねー #hokueng 2009-12-12 13:12:22
masayan_kazu ラダーのセクションにテストコード埋め込む作戦 #hokueng 2009-12-12 13:13:10
itsuki_kosen #hokueng 調べたら少しあった.ユーザにとってのアジャイル開発のメリット http://www.thinkit.co.jp/free/article/0608/3/2/ 2009-12-12 13:13:12
itsuki_kosen #hokueng 実践者インタビュー http://www.atmarkit.co.jp/farc/rensai2/prac01/prac01b.html 2009-12-12 13:13:43
shozzy ツールがテストコードを要求してくるわけか #hokueng 2009-12-12 13:23:21
rch850 cutagem でテンプレつくる。それで rake すると何もテストが無いという失敗になる #hokueng [VtP] 2009-12-12 13:24:47
shozzy 要求というより、自動でコケるテストコードを生成してくれるのか #hokueng 2009-12-12 13:25:04
hikaruworld 最近の #hokueng 2009-12-12 13:26:42
hikaruworld Eclipse+JUnitだと、自動生成したテストコードには、エラーfail()が実装されてたりする。 #hokueng 2009-12-12 13:27:27
shozzy よし、グリーンだ!きゅうけい! #hokueng 2009-12-12 13:30:57
kussy_y #hokueng のみなさんありがとうございました。ブログを書くまでがイベントですよ! 2009-12-12 16:57:36
wtnabe お届けタスク終了して帰宅なう #hokueng 2009-12-12 17:17:39
wtnabe えーとその後 tweet する機会がなかったんで補足しますと、今日使った道具は gem と rake と cutagem の http://github.com/genki/cutagem だけっすね。あとは Ruby 標準のものばかり。 #hokueng 2009-12-12 17:33:35
wtnabe コードの補完は Emacs でもやる人はすごいレベルでできるのですが、自分はそんなにヘビーには使い込んでないです。 #hokueng 2009-12-12 17:35:18
shoito 今年のコミュニティ活動をふりかえってきたよ – 北陸エンジニアグループ2009ふりかえり http://blog.air-life.net/2009/12/hokuriku-engineer-group-retrospective.html #hokueng 2009-12-12 23:27:26
katzchang ちなみに、今回の参加表明曲線です。 #hokueng http://f.hatena.ne.jp/katzchang/20091213030326 2009-12-13 03:04:36

#hokueng – ハッシュタグクラウドより。

Posted in program | タグ: , , | Leave a Comment »

開発プロセス勉強会に行ってきた(2009/05/16)

Posted by hikaruworld : 2009 5月 24

えーと、今更なんですが、一週間前wに開発プロセス勉強会に行ってきました。

現在諸事情により、平日は家ではPC禁止になっておりorz…
と、とりあえず、勉強会の内容の詳しくはここに書かれています。

以下、印象的だった事を断片的に。

  1. JUnitのテスト名は日本語!!
  2. TDDは品質管理のテストではなく、プログラムを稼働させるためのテストである。
    だから、極端にreturn 10とかやってもよい。簡単に実装することが大切。
  3. そのため、TDDのテストはそのまま品質テストとはなり得ない。
  4. じゃあCIのテストって何よ?
  5. 新人さんとペアプロする際に思考をトレースするのに便利そうだ。

1.JUnitのテスト名は日本語!!

nagiseさんの言う通り、やっぱり自動テストは日本語!!
JUnit4になって@Testのおかげでメソッド名のprefixに【test】をつけなくてよくなったし。
何十というテストを実行した際に日本語のメソッド名は見ててわかりやすい。
# まぁ、句読点がメソッド名に利用できないのはちょっともどかしいけど。

2.TDDは品質管理のテストではなく、プログラムを…

なるほど、と納得。
最初にがっちり自動テストを書いても、easymockとか使っていると、
結局、最後にコードの修正が必要になってきちゃうんだけど、
そもそも考え方が違うってことね。
まずはテストを通す(green)にする。その際に問題になることはTODOとして書き出す。

3.そのため、TDDのテストはそのまま品質テストとはなり得ない。

同上。

4.じゃあCIのテストって何よ?

この辺は、まとまっていないので別エントリで。

要するにTDDとCIをやっているときに、リポジトリへのコミット時のテストプログラムは
どういう位置づけになるんだろうというお話。

5.新人さんとペアプロする際に思考をトレースするのに便利そうだ

新人さんにものを教える際に、結果は把握できるけど過程がどうなったかいまいちわからない事が多い。
(新人さんがうまく説明できないことも含めて)
その辺りをリアルタイムに思考の流れをアウトプットして補正しやすいから、
教えやすいなとも思った。

その他

最も印象に残ったのは、やはりMac率。

Windows 2
Mac 5
FreeBSD 1

うーん。すばらしい。

あー、あと自分だけはてなID持っていないんだなぁと、ちょっと涙目。
このblog書いているときもそうなんですがid:hogehogeとかかけないのは結構面倒。

それと、テスト駆動開発入門の内容が色々な意味で難しい。
とりあえずデザインパターン知っている前提だったり、不思議な言い回しがあったり。
# 後者はともかく、前者は初学者には厳しいと思う。
# 少なくとも副作用の意味を自分はすぐに理解できなかった。

そうそう、誰もやっていない見たいのでテスト駆動開発入門のeclipse版を作成してみようと思う。

Posted in program | タグ: , | Leave a Comment »