カテゴリー「*コラム」の30件の記事

2011年12月25日 (日)

[TDD Advent Calendar jp: 2011] TDD とアジャイルを支えるバックボーン #TddAdventJp

このエントリは、TDD Advent Calendar jp: 2011の12/25 最終日のエントリーです。

前日は @aoki1210 さんのエントリ 「TDDに関する記事のリンク集」 です。
初日は @setoazusa さんの 「#tddbc の作り方」 でした。
全記事の一覧は、 ATND の募集ページ にあります。


はじめに、 ちょっと全体の感想やイキサツなどを。

こんな素晴らしい Advent Calendar になるなんて、 夢のようです。 取りまとめ役をやらせてもらった幸運に感謝、 です。
良記事ばかりですが、 その中であえてひとつ選ぶとするなら、 TDD する / しない (テストファーストする / しない)、 あるいは、 やるならどこまでやるか、 といったことをパターン化しようという @kyon_mm さんの試み 「TDD戦略 -TDDを導入し進化させる方法-」(12/23) を挙げたいです。 私にはまったくなかった発想なので。 (TDD の定義が Kent Beck のと違っている点は難ですが。)

さて、 そんな素晴らしい TDD Advent Calendar jp: 2011 ですが…

そもそもの発端は bleis 伯爵にダマされたんですよね~w

bleis: @aoo_niku TDD Advent Calendar?
posted at 2011/11/11 13:44:13
bleis: @linerlock んじゃぁ立てますか
posted at 2011/11/11 13:56:53
biac: で、これはどこ? w QT @gab_km: RT @bleis: @aoo_niku TDD Advent Calendar?
posted at 2011/11/11 20:11:43

てっきり bleis さんが立ち上げてくれてると信じたのに~~~ f(^^;


昨日までの記事で TDD の中身に関しては語りつくされた感もあるので、 最終日にあたるこの記事では、 TDD を支えるバックボーンの話をしてみたいと思います。

TDD は (それとアジャイルソフトウェア開発プロセスも)、 ソフトウェアの開発に特有の技法です。
ハードウェアの開発 (機械、 電子機器、 建築など) では、 できません。

続きを読む "[TDD Advent Calendar jp: 2011] TDD とアジャイルを支えるバックボーン #TddAdventJp"

| | コメント (0) | トラックバック (0)

2011年12月13日 (火)

[コラム] TDD の原点 ~ Kent Beck による定義

テスト駆動開発入門
2003/9 (原著は 2002/11)
著者: ケント ベック
翻訳: 長瀬 嘉秀
ISBN: 978-4894717114


Kent Beck が提唱した TDD。 彼はどのように TDD を定義しているでしょうか?
まだ 「テスト駆動開発入門」 を読んでいない人のために、 あるいは読んだけど前書きに書いてあったことまでは忘れてしまった方のために、 おさらいしておきます。

「テスト駆動開発入門」 は、 Kent Beck が TDD について初めて書いた本です。 その本の先頭にある 「まえがき」 より引用します。 (「まえがき」 の全文は、 Amazon の 「なか見! 検索」 で読むことができます。)

自動テスト、 TDD (テスト駆動開発) と呼ばれる開発スタイルにより、  不安を少なくして開発できる。 TDD では以下を実現する。

  • 自動テストが失敗した場合だけ、 新しいコードを書く。
  • 重複を取り除く。

これらはシンプルな規則である。

2つの規則はプログラミングのタスクにおける順番を意味する。

  1. レッド ‐ 動作しないテストを少しだけ作成する。 おそらく最初はコンパイルできない。
  2. グリーン ‐ テストをすぐに動作させる。 そのためには、 どのようなコードでもよい。
  3. リファクタリング ‐ テストを動作させるためだけに作成された重複をすべて取り除く。

「RED → GREEN → リファクタリング」という手順は、 TDD の説明としていつも言われることですが、 それは引用したように上記の 2つのシンプルな規則から導かれたものなのです。

この 2つの規則に則っていない技法は、 Kent Beck が定義した TDD ではないということです。

続きを読む "[コラム] TDD の原点 ~ Kent Beck による定義"

| | コメント (0) | トラックバック (0)

2011年11月 3日 (木)

[コラム] TDD は止めて、 DbE (例示による設計) と呼ぼう!

2年前に、 "It’s Not TDD, It’s Design By Example" (TDD じゃない、例示による設計だ!) というブログ記事が書かれています。
いちおう URL を挙げておきますが、 英文です。

Brad Wilson: It’s Not TDD, It’s Design By Example
April 18, 2009

記事の趣旨は、 TDD という名前が TDD の目的を表していない (だから、 改名しようよ) ということです。
「テスト駆動」という言葉からは、 その目的がテストによる品質保証であると誤解されかねません。 しかし TDD は、 メソッドの外部設計を自動化されたユニットテストという形で例示し (具体例で外部設計を説明する、と言っても良い)、 それを満たす実装を作り、 そしてリファクタリングによって内部設計を改善します (読みやすく理解しやすいコードにします)。 TDD の目的はユニットテストのレベルでプログラムの一部分を設計することにあり、 それは外部設計の例示から始まるので、 "Design By Example" (例示による設計) なんだ、 というわけです。

続きを読む "[コラム] TDD は止めて、 DbE (例示による設計) と呼ぼう!"

| | コメント (0) | トラックバック (0)

2011年10月31日 (月)

[コラム] NUnit の CollectionAssert で、 配列やリストを比較・検証する

NUnit (2.4.6以降) には、 コレクションを調べるための CollectionAssert があります。
簡単な動作説明用のコードを載せておきます。 (NotEqual系は省略)

続きを読む "[コラム] NUnit の CollectionAssert で、 配列やリストを比較・検証する"

| | コメント (0) | トラックバック (0)

2011年8月30日 (火)

[コラム] TDDBC 東京 1.6 のお題を C# でやってみる (その3) ~ 2つめ、3つめの仕様変更[T16MAIN-6,7]

前回は、 [T16MAIN-5] までやりました。 今回のこの2つの仕様変更は、 機能の追加です。 ですから、 新しいメソッドをどんどん TDD していけばよいです。

 
◆ ひとつめの機能追加

■ T16MAIN-6: dump の引数に時刻を指定できるようにする。 dump 関数は時刻が指定された場合、 指定時刻以降のデータのみを表示する
・dump の引数に時刻(秒単位)を指定できるようにする。
・dump 関数は時刻が指定された場合、 指定時刻以降のデータのみを表示する

Dump() の引数には、 何を渡せば良いでしょう? 「時刻(秒単位)」 という表現は、 .NET Framework 的にはちょっと解釈に困りますね。 DateTime 型にしておきましょう。
※ 後で、 「いや、 現在時刻から遡る時間(秒単位)だ」 ということになれば、 ラッパー関数を書けば終わりますからね。

すると、 オーバーロードする Dump() メソッドのシグネチャは、 次のようになります。

public IList<KeyValueTime> Dump(DateTime time)

続きを読む "[コラム] TDDBC 東京 1.6 のお題を C# でやってみる (その3) ~ 2つめ、3つめの仕様変更[T16MAIN-6,7]"

| | コメント (0) | トラックバック (0)

2011年8月18日 (木)

[コラム] TDDBC 東京 1.6 のお題を C# でやってみる (その2) ~ 最初の仕様変更[T16MAIN-5]

前回の記事で、 当初の仕様 (T16MAIN-1 ~ 4) を満たすコードは、 さっくり完成しました。 というところで…

TDDBC 名物、 仕様変更がやってまいりました!

T16MAIN-5: put の引数で key, value, date(時刻情報) を渡し、 dump を時間順に出力するように仕様変更
・ put の引数で key, value, date(時刻情報) を渡せるようにする。
・ また、 dump 関数は時刻が新しい方から古い方へ順に key、 value を出力するように変更する。
・ 引数に複数指定して追加する関数の場合、 後ろにあるものほど新しいとみなす。

ここまでは、 key と value を持つ Dictionary<string, string> コレクションを使ってデータを保持してきました。 しかし、 この仕様変更に対応するには、 時刻情報も保持しなければなりません。 さて、 どうしましょう?

続きを読む "[コラム] TDDBC 東京 1.6 のお題を C# でやってみる (その2) ~ 最初の仕様変更[T16MAIN-5]"

| | コメント (0) | トラックバック (1)

2011年8月 2日 (火)

[コラム] TDDBC 東京 1.6 のお題を C# でやってみる (その1)

2011/7/31 に、 3回目となる東京 TDDBC 「TDD Boot Camp 東京 1.6」 が開催されました。 当日の tweet は 「TDD Boot Camp 東京 1.6 #tddbc」 に纏められていますので、 参加できなかったかたはどうぞ。

かくいう私も参加できなかったわけですが、 午後に行われた実習の課題を C# でやってみたいと思います。 まず、 仕様変更が入る前まで。

続きを読む "[コラム] TDDBC 東京 1.6 のお題を C# でやってみる (その1)"

| | コメント (0) | トラックバック (1)

2011年2月 5日 (土)

[コラム] システム時刻に依存するメソッドをテストする 3 + 1 通りの方法

ユニットテストの天敵は、 外部に依存しているプログラムです。
依存しているものからの応答によってプログラムの動作が変わるとすると、 ユニットテストが困難になります。 たとえば、 データベース、 あるいは何らかの通信など。 もっとも身近なのは、 システム時刻でしょう。

次のようなメソッドを作るとします。

  • 現在時刻が午前だったら、 "Good morning!" と返す。
  • 午後だったら、 "Hello!" と返す。

このメソッドのテストケースは、 どう書きましょうか? 製品コードは、 どのようにしたらいいでしょう?
なにも工夫をしなければ、 1日に 1回しかテストが出来ないか、 PC の時計を変えてはテストを実行することになるでしょう。 何か工夫をして、 テスト実行時には PC の時計に依存しないようにする必要があります。 .NET Framework に用意されている DateTime.Now を製品コードで直接読み出すのはやめて、 テストコードから設定した時刻が読み出せるようにします。

その方法には幾通りもありますが、 私がよく使っている 3通りの方法を紹介します。

  1. メソッド内でシステム時刻を使わない
  2. #if ディレクティブを使って切り替え
  3. フェイクオブジェクト

※ C# 2010 Express Edition と NUnit 2.5.9 用のサンプルコード
  ⇒ TestDepnedingSystemClockMethod.zip (32,795 バイト)

続きを読む "[コラム] システム時刻に依存するメソッドをテストする 3 + 1 通りの方法"

| | コメント (0) | トラックバック (0)

2011年1月17日 (月)

[コラム] F# で TDD (@TDD道場#06)

わんくま名古屋勉強会#16 (2011/1/15) の TDD 道場では、 F# で FizzBuzz をやりました。
登壇していただいた 4名の方、 ありがとうございました。 会場には F# を見るのも初めてという方が多かったかと思いますが、 楽しんでいただけましたでしょうか。

テストコードの全体と、 製品コードの途中までは、 「[コラム] F# で NUnit するには」 に掲載してあります。 また、 当日のスライドとソースコードは、 「勉強会などで使った資料」 からダウンロードできます。 ここでは、 コードが成長していく様子と、 最後のリファクタリングについて書いてみます。

テストファーストでは、 失敗する (NUnit ランナーがレッドを表示する) テストケースをひとつ書いて、 それを通すように製品コードを追加・修正してそのテストケースを成功させます (グリーン)。 そのステップを示すと、 FizzBuzz では次のようになります。 (太字にして色を付けた部分が、 そのステップで変更・追加したところ。)

続きを読む "[コラム] F# で TDD (@TDD道場#06)"

| | コメント (0) | トラックバック (0)

2011年1月 9日 (日)

[コラム] F# で NUnit するには

To write unit-tests with F# and NUnit, as follows.

  1. Add reference to nunit.framework
  2. To declare the class, use the "type" keyword. Then, add "TestFixture" attribute.
  3. To declare the instance-method, use the "member" key word. And, give "Test" attribute.

Please look at the following sample code. Enjoy Test-First!

Fsharp_and_csharpexpress F# は、 無償でも使えます。となると、 TDD.NET としてはテストファーストしてみないわけにはいけません。
といっても、 NUnit への参照を設定してあげれば、 Assert クラスを呼び出すことは普通にできます。 あとは、 TextFixture などの属性をちゃんと付けたクラス定義が出来ればよいだけですから、 分かってしまえば難しいことはありません。 いつもの FizzBuzz をテストするコードは、 次のようになります。 コメントに C# との対比を書きました

続きを読む "[コラム] F# で NUnit するには"

| | コメント (0) | トラックバック (0)

より以前の記事一覧