BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ テスト に関するすべてのコンテンツ

  • InfoQ.comのデータベース更新: ほとんど成功、少し失敗

    この程、InfoQ.comはこのサイトを始めてから使用していたバックエンドのデータベースを刷新した。しかし、すべて計画通りに事が運んだわけではなかった。ほとんどの移行作業は滞りなく進んだが、いくつかの予期していなかった問題(現在は解決済み)に直面した。この記事では、私たちがどんな計画をして、何が成功し何がうまくいかなかったのか、そして直面した問題をどのように検知し解消したのかを詳しく論じたい。

  • Jim Shore氏、自動受け入れテストは正しい手段ではないと語る

    一般的に認められたアジャイルの文献のほとんどが、ユーザのニーズをとらえる最善の方法は、受け入れテストにエンコードされたサンプル、すなわち「自動受け入れテスト」であると教えている。だが、思想的リーダーであるJim Shore氏はそうではないだろうと言う。その一方で、彼に異を唱える人たちもいる。

  • Visual Studio 2010のカスタムコード分析

    マイクロソフトのコード分析ツールであるFxCopは、数年にわたって、カスタムコード分析ルールの作成をすることができると提案し続けているが経験は芳しくない。 VS2010バージョンでは、いくつかの改善とよりよい統合シナリオを提案しているが、いくつかの根本的な問題が残っている。

  • 一時的なコードと継続的に使うコード、そしてその間にあるすべてのコード

    よくテストされリファクタリングされた長く使われるコードがある一方で、数日で捨てられることを前提にして書かれるコードもある。そしてこの両極の間に巨大なグレーゾーンが横たわっている。このグレーゾーンに属するコードはいつか削除されるという想定の元に書かれているが、決して消されることがない。

  • Spring.NET 1.3: VS.NET ソリューションテンプレート MSTest サポート,そして Spring Integration.NET

    Spring.NET フレームワーク の新バージョンである version 1.3 が先頃リリースされた。InfoQ ではプロジェクトの創設者でリーダでもある Mark Pollack 氏に,同プロジェクトの詳細と今回導入された新機能,そして新プロジェクト Spring Integration.NET の詳細などを聞いた。

  • .NET Reflectorが商用に

    Reflectorは多くの.NET開発者にとって必須であろう。サードパーティ製ライブラリのデバッグや言語間の翻訳、単純に自分で作ったコンパイル済みコードを見てみるといった用途で、Reflectorは不可欠なツールとなった。さらに、これまでは、Reflectorもそのアドインもフリーソフトとして使うことができた。

  • リーン+リアルオプション=複雑さとリスクの低減

    リア��オプションとは、金融オプション数学に基づく意思決定プロセスである。これは通称「白本」とよばれるExtreme Progamming Explainedにおいて、Kent Beck氏が1999年に言及しているものだ。近年ではアジャイル主義者たちがリアルオプションがアジャイルとどのように交わるのかについて調査してきた。現在はChris Matts氏とOlav Maasson氏が、特にリーンソフトウェアコミュニティに対して発言している。リアルオプションを採用することでリーン開発が改善するというのだ。

  • 安定化スプリント - 必要悪か、それとも純粋な無駄か?

    安定化スプリント("Stabilization Sprint")とは、製品をリリースする前、通常の開発サイクルの最後に付け加えられる付加的なスプリントである。名前が示している通り、このスプリントは通常プロダクトを最後にもう一度叩き、最後のバグを出すためのものである。これはアジャイルに属するものなのか?それとも「完了」すれば充分なのか?

  • あなたがやっているのはテスティングかチェッキングか?

    ソフトウェアテスティングとは、ステークホルダにテスト中の製品やサービスの品質に関する情報を提供するために実施する、経験的調査のことだ。しかし、この定義では、テスティングとチェッキングの微妙な違いを生む「知恵」については語られていない。Michael Bolton氏は、これら2つの違いと、その違いがある理由について語った。

  • メンテナンス可能な自動受け入れテスト

    自動テストはすぐに辻褄が合わなくなってしまい、メンテナンスするのが大変だ。従って企業もテストを自動化したがらない、とDale Emery氏は言う。氏は、最近公開したペーパーにテスト自動化に関わる共通の問題を回避するための実践的な方法を記している。これは、典型的な自���化コードから始めて、より強力でメンテナンスしやすいコードに育てていく方法だ。

  • 進捗の思わしくない Code Contracts

    Code Contracts の製品開発利用への展開が進んでいない。当初からあった数多くの技術的目標は今も有効だが,目前にある問題や障害のために,現在の形式での実現は遠からず断念せざるを得なくなる。

  • システム/受け入れテストで日付型と時間型をテストする

    単体テストで日付と時間をでテストする方法はよく話題にあがるが、比較的簡単な解決策がある。もっと難しいのは、時間を受け入れ/システムテストでテストすることだ。どんな方法があるだろうか。

  • テスト駆動開発とレガシーコードのトラブル

    Alan Baljeu 氏は大規模なレガシー(古い) C++ コードベースへの TDD 利用を試みていた。そこで「可能な限り簡単に (simplest thing that could possibly work)」という原則が原因になって,大きな手戻り作業の発生するトラブルを経験したのだ。

  • RubyMine 2.0 - 動的開発へと続く道

    第1級の Ruby IDE のひとつが JetBrains 社の決断によって商品化された。バージョン 1.0 のリリースから6ヶ月を過ぎた今日,リリースされる RubyMine 2.0 がそれだ。

  • Bobおじさんが述べるTDDの適用可能性

    "TDDによってペースが鈍ると考えている人は石器時代で生きつづけているようなものだ"と主張したことで議論を巻き起こしたブログに続き、Bob Martin氏は現実のTDDの適用可能性、役割、恩恵に対する深い洞察を試みている。

BT