TDD
最近は原点回帰でボーリングのスコア集計プログラムを書いてみたりしているのですが、平鍋さんのblog記事経由でパターンマッチを使う例を(5年遅れで...)見たので、僕もScalaで書いてみました。 object Bowling { def calc(score: List[Int]): Int = { def ne…
TDD Boot Camp名古屋の2日目に参加しました。2日目はレガシーコード(=テストコードのないプログラム)改善体験ワークショップということで、午前中はid:t-wadaさんのライブコーディングによるデモ。午後は言語毎にグループに分かれて改善実践ワークを行い…
二日続きのTDD(Test-Driven Development: テスト駆動開発)ワークショップに参加しています。 ワークショップはいろいろなプログラム言語のプログラマーの人たちが参加しています。Java, Ruby, C#, C++, Scala, OCaml(!), VB, e.t.c. 僕は仕事でよく使うC++で…
ケント・ベックは、テスト駆動開発はテスト技法ではなく、ソフトウェア開発のすべてのアクティビティを構造化する手法である、と言っていて、構造化というキーワードが気になりました。構造化プログラミングってのは、サブルーチンを使えとかgoto文は駄目だ…
Check: A unit testing framework for C というのを見つけたのでドキュメントを眺めていたら Other Frameworks for C - Check 0.9.5 ということで、いくつかのフレームワークが紹介されていました。いくつかのものは知っていました。GNUのものは知らなかった…
僕個人的には構造化されたコードが好きで、コメント書く位なら関数に切り出すのがいいと思っている(いた)。でも、これって本当に好き嫌い。僕の中には合理的な理由があるけれど、僕と同じ嗜好を持っていない人には、説明はできるものの説得なんてできた試…
プロダクトコードに手を加えたければ、まず失敗するテストを書かなくてはならない。このテストファーストの教えは、テストコードとプロダクトコードを同期させていくとても合理的な方法だ。なんだけど、たとえば初めての人には敷居が高いとか、難しさもある…
プログラムってかわいそうだと思った*1。ある日プログラマによって書かれシステムや製品の一部になるけど、引き継いだ保守担当者になにこのう×こコードなんて言われたりする。思えば生まれてこのかた、プログラマの勝手な好み(コーディングスタイルとか、設…
議事録ドリブンな会議とテスト駆動開発は似てる。議事録ドリブンな会議は、議事録を書くことを中心に据えることで、議論の無制限な発散やあいまいな終結を避ける会議のやりかただ。プロジェクターにPCを繋げてリアルタイムに議事録を取り、合意事項をどんど…
諸般の事情でC言語で書くことになったプロジェクトに、なんとしてもユニットテストを持ち込みたいと思っています。単体テストを自動化して繰り返し実行できるようにしたいのです。関数毎に、入力に対して出力をチェックする、というのはいいでしょ。構造体を…
もともとテストにはふたつの意味があると思います。 バグを見つける バグがないことを示す 前者は、作成中のソフトウェアにはなにがしかのバグが含まれていて、これを取り除くためのテストです。境界値分析やバグ推測に基づいて行うテストは、効率良くバグを…
XPエクストリームプログラミング第二版。参考文献「オブジェクト指向入門」(B.メイヤー)に対する解説。 契約による設計は、ユニットテストに代わる方法、または、ユニットテストの拡張である。 ユニットテスト(を使ったテスト駆動開発)って、コーディン…
テスト駆動開発だと、外付けのユニットテストを書くためにインタフェースを意識して考えることになる。これによる設計の質の向上がある。また、ユニットテストで仕様を縛るので、不用意に仕様を変更してしまうことによるトラブルも減るだろう。また、テスト…
テストをすこし、コードをすこし、は実演できた。しかし! もうガチガチに組まれているmake環境にテストを入れ込めない ハードコートされた絶対パス等が邪魔をして、修正対象のモジュールを単体で動かせそうもない 根気よくやればできると思うけど、ガッツと…
Java World (ジャバ・ワールド) 2005年 11月号の特集「テスト・ファーストによる設計」を読んで。形式手法というのはぜんぜんピンとこないんだけど、スペック記述としてのテストをモックを使いながら書いていくことで、実装に踏み込まずして実行可能な仕様を…
外付け表明と考えるか、本体コード変更申請書なのか。 実際はどちらでもあるのでしょうけれども。 テスト対象のあるべき仕様をテストとして表現する つまり最初は(=基本は)ブラックボックス そのテストにパスするように実装する 実装の都合上、既存のテス…
http://d.hatena.ne.jp/amapyon/20050410ちょっと論点が違うかもしれませんが、実装のテストは仕様に関するテストとは別になっているほうがいいなあ、んで、実装にべったりなんだから実装のそばにあるのが自然かも、と思いました。実際にそういう風に書ける…
思うに、C++では、オブジェクトはスコープの始めにスタックに取ってスコープアウトで破棄するのが美しい しかし多態性を利用するためにポインターか参照によるアクセスが必要 すなわち積極的に多態性を使わせようとしていないと思わざるを得ない でも、そん…
基本的にはケースバイケースなんでしょう。その依存性がどの程度単体テスト容易性を阻害するかによって、その依存性を排除するためのコストをどれだけかけてよいのかが決まる、と。でもね。だとすると、ケースバイケースでべったり依存だったりそうでなかっ…
依存関係にあるクラス(以下の例だとLock)をMock置き換え可能に保ちたくて、ファクトリー(LockFactory)をインジェクションしてみました。 class Lock { public: virtual ~Lock() = 0; }; class LockFactory { public: virtual Lock * create(const char *…
コラボレーターはコンストラクタまたはセッターで与える設計にするのがお作法、ということになるんだろうか。 DIコンテナを使う使わないにかかわらず? て言うか、DIコンテナは使わない(使えない)けど、ユニットテストし易くしたいので そのコラボレーター…