すいません、VB4しかやってないんです、VBAはやったけど(ぼそ) チラシの裏だって立派な書き込み空間なんだからねっ!資源の有効活用なんだからねっ!とか偉そうに言ってるけど、実は色々と書き残したいだけ

だからなに? どうしろと? くるみサイズの脳みそしかないあやしいジャンガリアンベムスターがさすらう贖罪蹂躙(ゴシックペナルティ)

ホーム 連絡をする 同期する ( RSS 2.0 ) Login
投稿数  632  : 記事  35  : コメント  2130  : トラックバック  143

ニュース


片桐 継 は
こんなやつ

かたぎり つぐ ってよむの

大阪生まれ河内育ちなんだけど
関東に住みついちゃったの
和装着付師だったりするの
エセモノカキやってたりするの
VBが得意だったりするの
SQL文が大好きだったりするの
囲碁修行中だったりするの
ボトゲ好きだったりするの
F#かわいいよF#

正体は会った人だけ知ってるの

空気読まなくてごめんなさいなの


わんくまリンク

C#, VB.NET 掲示板
C# VB.NET掲示板

わんくま同盟
わんくま同盟Blog


WindowsでGo言語
WindowsでGo言語


ネット活動


SNSは疲れました

記事カテゴリ

書庫

日記カテゴリ

ギャラリ

イベント活動

プログラムの活動

はじめに

この記事はTDD Advent Calendar jp: 2011 : ATNDの参加記事です。

私で21日目に突入しました。20日目は、haru012さんの

Testing と 私と 苦い出来事

でした。体験談かぁー。私も炎(ry ごほんごほん。

てな感じで、今までの記事では、TDDの色々がとてもお勉強になるお勧め記事がたくさんでしたが、私のはちょっとだけ業務アプリケーション開発の実作業に近づいた内容かもしれません。まぁ、実際の所、私はこんな風に思ったよ、というのが正しいのですけれども。

MVCとTDD、それぞれの利点

MVC(Model-View-Controller)と呼ばれるデザインパターンが流行ってます。実際、私も使ってます。MVCって何?って方は以下など読んでいただいて。

Model View Controller - Wikipedia
 
MVCとは【Model-View-Controller】 - 意味/解説/説明/定義 : IT用語辞典

読んで字のごとく、MVCはアプリケーションの構造をModelとViewとControllerという3つの概念に分けるものなのですが、これらの開発過程でTDDを生かして進めていくとかなり有効。というのも、それぞれの利点がうまく重なっているんです。

まず、私が考えているMVCの利点は次のような所。

  • MVCそれぞれにクラスが独立していて、作成するコードの単位が明確である。
  • メソッド単位、アクセサ単位で処理を隠ぺいできるので、既存コードへの影響が少ない修正作業、リファクタリングをすることが出来る。

そして、TDDの利点は次のような所。

  • 仕様が理解できているか、抜けが無いか、自己確認が出来る。
  • リファクタリングや仕様変更によるデグレードを防ぐことが出来る。
  • メソッド単位、クラス単位の小さなテストコードを積み重ねるので、全体がどれくらいで、今できているのがどれくらいなのか判り易く、進捗を取りやすい。

つまり、それぞれの利点の共通点は、

プログラムコードにしろテストコードにしろ、実際に作業する単位が小さい。

こと。ここ、以外と大事。独りでちまちま作るにしろ、チームで作業を分けあうにしろ、TDDで作り上げていくMVCのアプリケーションは、小さな単位を積み上げていくってことが同じだから作業に無駄がない。実際に、たくさんのテストコードがGreenになるのは楽しいし<結局そこか(笑)

効率良いTDDをするために

小さな作業単位を積み上げていくのは良いけれど、それらをもっと効率的に確実にできる方法はないのでしょうか?

例えば、チームでMVCそれぞれを担当して並行してすすめる、とか。恐らくは「独立したテストコード」を作成できれば、その理想に近づく事は出来ると思うのですけれど……。

MVCは独立しています、といっても、それぞれのクラス、メソッドで動作するプログラムは動作の前提条件や変数の内容などで密接な関係があることに違いありません。こっちが出来てないと、データこないじゃん、データないじゃん、ということはフツーにあるわけで。

そこで、テスト用クラス、Mockというクラスの考え方が出てきます。

極論、Modelのクラスを作成したい時には、Modelクラスだけがテスト出来れば良いわけです。その他のViewクラスやControllerクラスが、未実装だったり、まだバグがある状態だだったり、そんな状態で使っていたら、本来のModelクラスのテストはいくら頑張っても効率が上がらない。だから、その対策として、Modelクラスの目的の動作に必要な前提条件、テストデータ、それらを備えたクラス、Mockクラスを用意するのです。それを使う事で、前提条件がそろった状態で実行できますから、自分は必要な最低限のModelクラスの動作だけをテストコードに記述すればよいですね。

具体的に、データベースからレコードを取得して一覧に表示する、を例に考えると、

  1. データベースからデータを取得する。
  2. 一覧表示用のリストデータに加工する。
  3. リストデータから一覧表示を行う。

とMVCの単位で大まかに分けることができます。実際にはもっと色々とあるかもしれないけど、例なので大雑把(笑)。この時にTDDしよう!と思ってテストコードを書き始めた時、1を作って動作できたら、2を作って、2が動作出来たら3を作る、とやっていかないと、必要な前提条件(データ)がそろわない。

でも、

  1. データ取得ためのデータを提供するデータベースのMock
  2. リストデータ加工するためのソースデータを持つクラスのMock
  3. リスト用データに加工済みのデータを提供するクラスのMock

がそれぞれにあれば、1~3のクラスを並行に作業可能。自身以外の必要なクラスはMockに任せてしまってるから、本当に自分が作りたいクラスとメソッドの動作を検証するだけのテストに特化でき、TDDのサイクルも早くなります。

つまり、Mockクラスを使う事で「独立したテストコード」が可能になるんです。

ちなみに、実際にテスト用Mockを使ったテストを行う時、良い仕事をしてくれるのがInterfaceクラス。Mockに置き換えたいクラスがInterfaceを持つことで、呼び出し側はMockなのかそうでないのか、意識する必要がなくなります。DI(Dependency Injection)できるフレームワーク上でのTDDなら、なおのこと、必要に応じてMockを注入できるからお勧め。

TDDの肝

こうなってくると、Mockを作成する=Mockの内容に仕様と齟齬があったら、なかなか大変なことになるのでは?と思いませんか?

Mockの作成もさることながら、テストコードの作成にしてもそうです。テストコードの品質=作成されるアプリケーションの品質、と考えても過言ではないでしょう。あくまでもこれは経験則ですが、TDDの肝は、言語やフレームワークに関係なく、まず仕様の理解が必要不可欠であり、それをいかにテストコードに反映できるか、だと思っています。なんて偉そうに言ってても、まだまだ私も修行中の身、仕様理解できてない、勘違いしてた、がよくあってorz。

TDDは小さな単位でプログラムコードの動作を検証でき、それを積み上げていくことで磨かれていく開発手法です。MVCパターンとも相性がよく、うまく使えば非常に有効な手段でもあります。

というわけで、私の記事は終わりです。最後に、TDDに携わるようになってから覚えた、自戒の意味をこめて、この言葉を。

 

「書いていないテストコードにバグがある」

投稿日時 : 2011年12月21日 6:08

コメント

# re: 私、MVCでTDDやってます。 2011/12/21 9:43 PATIO
TDDに関しては社内でも何度か提案をしたり、
啓蒙活動も試みましたが、結局本気で取り組む所まで行っていません。

作業者レベルでは利点等を理解してくれている人もいるんですが、
結局は従来のやり方に押し流される形になっています。

テストクラスの記述は
仕様についてホントにそれで良いのか
と言う自問自答の機会になるので非常に有意義であると思っています。
テストクラスの記述をする事で明記されていなかった仕様の漏れに気づいたりしますし。

ともあれ、自社でのTDD普及はまだまだ先になりそうです。


# TDD????????????????????????????????????TDD??? | YRL???Yuri Research Lab.) 2011/12/22 5:42 Pingback/TrackBack
TDD????????????????????????????????????TDD??? | YRL???Yuri Research Lab.)

Post Feedback

タイトル
名前
Url:
コメント