あけましておめでとうございます。今年もよろしくお願いいたします。 2008年の最初のエントリは、新年の挨拶もほどほどに、この冬休みの宿題の１つの成果報告をしてみよう。4つほどあった宿題だが、結果が出たのは１つのみである。なんとも情けない。。。 さて、昨年さんざん騒がれたRuby on Railsだが、「Javaな感覚」でRailsアプリを作ると、それはすなわち「Java以上の失敗プロジェクト」になる。「Javaな感覚」とは、つまり、コンパイラの存在。Javaにおいて、コンパイラが行ってくれる文法チェックやクラス間の依存性検証は、プログラマに対して非常に大きな安心感を与える。もっと言えば、非常に低いレベルとは言え、単体テストコードがなくても、コンパイラがあればなんとかリファクタリングができてしまうことも多いだろう。 しかし、Rubyにはコンパイラなどない。Railsの場合、プログラマがどこで
ニコニコ動画：https://www.nicovideo.jp/watch/sm2326646 第17回で、プロダクトコードの重複の話をしました。そこでは、DRY（Don't rpeart yourself）原則、コードの「重複は悪」という話をしました。 では、テストコードの重複はどうでしょうか？ 今回はその点について議論してみたいと思います。 テスト対象、納品対象のコードは、コードの重複や機能の重複というのは、あってはならない、というか理想的には1行も重複がないという状態で書かれるべきですが、ではテストコードはどうなのかという話です。 テストコードの中の重複をどんどん排除してくと、たとえばテストのヘルパクラスをたくさん作ったりとか、テストクラスの継承がどんどん深くなるといった結果になり、そのテストが実際にどのように動いているのかを調べるために、いろんなテスト用クラスを行ったり来たりしなけ
Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situations through hands-on training personalized to your needs, at your own pace or with our global network of learning partners. Take training Find
ニコニコ動画：https://www.nicovideo.jp/watch/sm2325911 宮澤さんの発言「俺ってばスゲー」という地点に達したあと、TDDの壁みたいなのはありましたか？ 俺ってばスゲー、TDDもスゲーと思ってから、はい、TDDの壁にはぶつかりました。「テスト駆動でできるところと、できないところがあると認識しなければならないところ」ですね。簡単に言うと、GUIを伴うテスト、画面を伴うテストっていうのは、すごく難しい。というより、割りに合わない感じが強いんですね。これは今でもそうです。 「テスト熱中症」「テスト厨」 テスト駆動開発をマスターするきっかけをつかんで、これはイケる！ これは素敵だ！と思った人が次に出会うのは、「テスト熱中症」「テスト厨」時代です。テストがすごく好きになり、テストに熱中する時期がやってくるんですね。 テスト熱中症（test infected）
TEST http://d.hatena.ne.jp/devbankh/201001 モックやスタブを使った効率的なユニットテスト http://d.hatena.ne.jp/devbankh/201002 モックとスタブの違い コミュニケーション http://d.hatena.ne.jp/devbankh/20051124 簡単かつ効果的に話すために "モックオブジェクト"という言葉は、テストのために本物のオブジェクトをまねる特殊なオブジェクトを表す言葉として定着した。しかしモックという言葉は元々スタブをキャッチーにしたものでなく、[スタブを使ったのとは別の] ユニットテスト方法を用いるためのものなのだ。この記事では、モックオブジェクトのファンに好まれる相互作用中心のテストと、よく行わている状態中心のテストスタイルとの違いを説明するために、モックとスタブの違いについて掘り下げる。 目次
///<summary> ///Subtraction (int, int) のテスト ///</summary> [TestMethod()] public void SubtractionTest() { Calculater target = new Calculater(); int i = 0; // TODO: 適切な値に初期化してください int j = 0; // TODO: 適切な値に初期化してください int expected = 0; int actual; actual = target.Subtraction(i, j); Assert.AreEqual(expected, actual, "CodeZineSample_UnitTest_VSTD.Calculater.Subtraction は 予期する値を返しませんでした。"
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
今回は、PHPUnit3の便利な機能とPHP版プロジェクトビルドシステムであるPhingとの連携について見ていきます。 既存クラスからテストを作成する さて、別の開発チームで作成していた決済用クラス（Checkoutクラス）が届きました。 <?php require_once 'Cart.php'; class Checkout { private $cart; public function __construct(Cart $cart) { $this->cart = $cart; } public function getSubTotal() { return $this->cart->getTotal(); } public function getShippingCharge() { if ($this->cart->getTotal() > 1500) { return 0;
テストにフィクスチャ（テストデータ）は欠かせない。普通、次のように使う。 class FooTest < Test::Unit::TestCase fixtures :foos, :bars # 読み込む対象のフィクスチャを指定 end こうするとテストのメソッドが呼ばれる前に test/fixturs にあるフィクスチャファイル (テーブル名.yml) をデータベースにロードしてくれる。 （実際にはキャッシュされるので、テストのメソッドが呼ばれるたびにデータベースにデータがロードされるわけではない・・・もしそうならあまりに遅すぎる） もし特定のメソッドでだけフィクスチャーをロードしたければどうするか？ Fixtures.create_fixtures を使う。 class FooTest < Test::Unit::TestCase def test_foo Fixtures.creat
Blog Development for RushCheck 0.8 is delayed (2006-12-04) Why does the development of Rushcheck seem to be delayed? There are several reasons that I may have to say. The main reason is that I’m now concentrate upon writing a paper whose deadline is Jan 8, 2007, which is not related to RushCheck, but my favorite mathematics. On the other hand, another reasons are related to RushCheck. I’ve two
自分でももやもやしてるのでツッコミ希望。 考えだした元記事 : http://techon.nikkeibp.co.jp/article/TOPCOL/20070806/137518/ TDDを紹介するときに、「TDDではプロダクトコードの前にテストを書く」という紹介のされかたが多いんですが、これはちょっと誤解を招く表現だなぁ、と思います。TDDを達成するための1つの(とても有効な)技法としてテストファーストがあるわけですが、その関係は"=="じゃなくて包含だよなぁ、と思うのです。 TDDは字義通りに解釈してもしなくても、テストが開発を駆動することが重要なわけです。駆動するというのはもちろん先にテストを書けば駆動してるんですけど、それは必要条件じゃない。 別にあとから作っても*1、 自分が作ってるモジュールを使ってみたら、APIが「ねーよwww」くらい使いづらいものであると気づいたり、とか
第2回 C++アプリケーションの効率的なテスト手法（CppUnit編）：連載 C++開発者のための単体テスト入門（1/4 ページ） 連載目次 前回は単体テストの重要性を示し、従来のC／C++でのテスト手法であるprintf関数やassertマクロを使ったテストを紹介しました。この2つのテスト手法は開発環境（コンパイラとライブラリ）さえあれば利用でき、その使い方も簡単です。しかしながら、いずれも系統立てて、効率よくテストを行うには力不足の感が否めません。 今回は、Visual C++ 2005 Express Editionを含むVisual Studio 2005（以後、VS 2005）で利用できる代表的な単体テスト・フレームワーク（Unit Test Framework）の1つである「CppUnit」を紹介します。 ■単体テスト・フレームワークとは？ 前回、「バグは早期発見が望ましい。早
RailsでのAgile開発実習はまだまだ続く。 今日は弟子一号[*1]の作品をリファクタリング。70行にしてすでにスパゲティ＋盲腸だらけという状態のコントローラクラスを21行まで減らす。 はてなのブログでは「オブジェクト指向とはなんぞや」「どうやったらオブジェクト指向を習得できるのか」という議論が盛んだけど、自分は「それ、どうやってテストするの？」という視点で考えるようにしている。ここでいうテストとはテストコードで機械的に片付けるテストのことね。手動で操作して「動きました」というのは論外。 もちろん、汚いコードでも頑張れば[*2]テストコードを書ける。でも、汚いコードはテストコードを書くのも大変だし、かなりの確率でテスト漏れが生じる。テストコード作成が楽なコードが即オブジェクト指向的に正しいかというと必ずしもそうではないのだろうけれど、品質でつまづく確率はか〜なり低くなる。 なので私はオ
_ いまさらTDDを見直す いまさら「フェルマーの最終定理 (新潮文庫) 著:Simon Singh 訳:青木 薫」を読んだ*1。この本はすごくいい。 この本が指し示していることのひとつは、皆、汗かいて土木作業してたってことだ。ピタゴラス、ユークリッド、…、オイラー、ガウス、…、ソフィー・ジェルマン、…、志村=谷山…。 綺麗な命題/予想を産み出した彼/彼女らは、手を動かす計算をむちゃくちゃな量やってる。 型理論によれば、型は命題で、実装は証明にそれぞれ対応する。そして、テストは、実装の仕様記述の一部に対応する。具体例を計算することはテストすることだ、と言える。 つまり、XPとかTDDとか誰かが言い始めた2000年前から、数学家はひたすらテストファーストだったってこと。証明/予想を言い終えた後は、テストの結果は焼いて捨てたから残っていない。 反論もありそうなことを敢えて言うが、私自身、テスト
アプリケーションを開発する上で、避けて通れないもの、それがテストです。とくにブラウザごとの非互換性が大きい Web アプリケーションでは、念入りなテストが必要です。でも、テストはあまり創造的な作業ではないし、やったからといってなにか機能が増えるわけでもない。できるだけ手間をかけずに済ませたいところですね。 そんなわけで、本日は JavaScript 用のテストフレームワークである JsUnit を利用したユニットテストの方法をご紹介しようと思います。 Ruby のユニットテストの記事でも書きましたが、ユニットテストによるテスト・ファースト開発は開発効率の面でも良い影響があります。まだ導入していない方は、ぜひこの機会に使ってみてください。 JsUnit について 今回利用する JsUnit は Java 用の JUnit を参考にして作られた JavaScript 用のユニットテストフレーム
TddAntiPatterns - TDD のアンチパターン 目次 この文書について TDD のアンチパターン TDD アンチパターン・カタログ 嘘つき。 (The Liar) セットアップ過多 (Excessive Setup) 巨人 (The Giant) モック酔い (The Mockery) 検査官 (The Inspector) 太っ腹な残り物 (Generous Leftovers) 地元の英雄 (Local Hero) 小姑 (The Nitpicker) 秘密のキャッチ (The Secret Catcher) ペテン師 (The Dodger) 大声 (The Loudmouth) はらぺこキャッチ (The Greedy Catcher) 序列屋 (The Sequencer) 隠れ依存 (Hidden Dependency) 点呼 (The Enumerator)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く