2010年1月28日

The Art of Unit Testing

[ ソフトウェア開発 ]

最近読んだ"The Art of Unit Testing: With Examples in .net"という本がとっても良かった。Unit Testをはじめようとしているひと、運用で悩んでいる人は今すぐ読め! ってくらい良かった。

この本は、ユニットテストの基本的な考え方と基本的な書き方から始まります(Part 1)。

そして、ユニットテストで必須のテクニックである依存性の取り除きかたについて語られます(Part 2)。

その上で、ユニットテストをどう配置し走らせるか、どうやってリファクタするか、どんなふうに自動ビルドで運用するか、など実際に運用するときの考え方や方法論を解説します。そしてユニットテストのコードで陥りがちな罠(ひとつのテストにAssertion多すぎ、テストの名前が分からん、Setupに詰め込みすぎ、実行順序に依存、などなど)とその回避基準も明示します(Part 3)。

さらに、組織へのユニットテストを導入するにはどうするか(新しいことには抵抗がつきものです)を説明し、「タフ」な質問( 「これはどのくらい時間をとるの?」「これでほんとに効果がでるの?」など)にどう応えるか、回答例のカタログとともに説明します。最後の章では所謂"レガシーコード"に、どのようにユニットテストを適用していくのか、という話題に切り込みます(Part 4)。

上記で要約したとおり、「ユニットテスト」の話題に関する1から10までをカバーしてる本です。これだけ盛りだくさんで、厚さは300ページ程度と薄いのもよいです。でも内容は決して薄くないですよ。これからユニットテストを学ぶひとが最初から通読するのにはとても向いていますし、ある程度実践してるけど、いろいろうまくいっていない人(それは私)にも読み応えあります。

テスト駆動開発ベースの本や、JUnitの使い方の本はいままでもいろいろありましたが、ユニットテストの話題を網羅した、適切なサイズの本はこれまでなかったのではないかと思います。

"xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series)"や、"レガシーコード改善ガイド (Object Oriented SELECTION)"を読む前に読むのもよいのではないかと推測します(推測なのは、どっちも未だ読んでいないので...)

翻訳されていないのが惜しいです。もし誰も版権とっていないのならば、翻訳したいなー、と本気で思っています。アンオフィシャルに蠢き中ですが、既に翻訳はじまってるよ、などの情報ご存じの方いらっしゃったら教えてください。

そして、ひろってくださる出版社募集中。

2010年1月24日

アレグザンダー祭りで印象に残った一言など

[ イベント ソフトウェア開発 休むに似たり ]

先日、オブジェクト俱楽部のイベントアレグザンダー祭りに行ってきました。もりだくさんすぎて、未だに消化しきれていないのですが、一点強烈に印象に残ったのは、メインスピーカのJim Coplien氏による、おおむねつぎのような発言です。

俺たちは有用性が証明されたかどうかでなく、流行や気持ちよさ、直観、「のみ」で技術や方法論を追いかけている(ことが多い)

今週になってからtwitterでの議論の中で、こんな発言がありました:

if your only learning comes from asking other people what *they* think - how can you claim to personally know anything?
(このひとは、The Art of Unit Testing: With Examples in .net の著者です。良書なので近々紹介します)

これは開発関連のツールに関連した議論の中で出てきた発言です。意図は、先のJim Coplienの発言と同じだと、私は理解しました。

肝に銘じます。

2008年7月15日

iPhoneアプリが作りたい

[ ソフトウェア開発 ]

無事手に入ったことだし、iPhoneアプリが作りたい! と思っているのですが...
  1. 暇がない(言い訳、暇なんかつくればいくらでもある!)
  2. ネタがない(これは深刻かも。アイディアの種はちょっとだけあるので、育て中です)
  3. iPhone SDKにとっかかれない(これも言い訳
3.については、まあ言い訳ではあるものの、なんかきっかけがあればなあ、と思っていて、ここで提案されている勉強会が開催されるならぜひ参加したいなと思っています。

2006年5月 3日

subversionメモ

[ ソフトウェア開発 ]

完全に自分用のメモです。Railsとかでちまちま作ってるもののバージョン管理やらなきゃってことで。switchtower(名前かわったみたいだけど)も調べないと

MacOS X用クライアント

ここにバイナリが

http://metissian.com/projects/macosx/subversion/

サーバーは? svnってapacheがいるんじゃないの?

  • ローカルファイルをレポジトリとして使う方法がある。
  • svnserverでもいい。
  • どうしてもっていうならApacheでWebDAV

つかいはじめ

% svnadmin create レポジトリへのパス
% svn import file:///レポジトリへのパス/theProject -m "なんかメッセージ"

日常のつかいかた

coでもってきて、できたらci。CarbonEmacsパッケージにはvc-svnがはいっている。C-x v vでco/ci。複数ファイルの一括が分からない。日本語のログで怒られる

trunkとかbranchとか

コンベンションとして名前を付ける意味がいまいちわかってない

2006年2月11日

わざわざ「自動生成」と名乗るものは

[ ソフトウェア開発 休むに似たり ]

System.exit(); - 自動生成ってなんかダサい

自動生成ってなんかダサいと思います。 いや、ダサいとかそうい問題じゃなくて、必要な時と場合もあるってのはわかるんですけどね。 自動生成ってのは、なにかのギャップを埋めるための暫定対応的なものなんじゃないかと思います。

同感。

例えばバーチャルマシンを例にあげると、あれって要はマシンが実際に実行するための命令を自動生成しているわけですよね。

てゆーか、コンパイラってマシンコードの自動生成器ですよね。

ソフトウェア開発の世界では、自動生成されたものをいじることが想定されていない場合やいじる必要がない場合、そのメカニズムを「自動生成」と呼ぶことはないように思います。JavaコンパイラがJVMコードを自動生成する、なんていいませんよね。自動生成を名乗るメカニズムは、生成されたものに人間があとから手を加えることを想定しているのではないでしょうかね。

生成されたバイトコードに手を入れないと使えないJavaコンパイラみたいなものですね、といったらいいすぎかな。初期のC++コンパイラはCのコードを生成するプリプロセッサでしたが、そっちのほうが近いかな。

自動生成といえば、設計モデルからコードを自動生成する、とか、制約として記述した仕様からコードを自動生成する、なんて話があります。私はこれにも懐疑的なんですが、書いてみようとしたらあんまり知識がない上に考えがまとまっていないことが分かったので出直してきます。