TDDを使用した複雑なコードの良い例[終了]


37

大規模な現実の複雑なプロジェクトでTDDを使用する良い例は何でしょうか?これまでに見た例はすべて、本や論文を目的としたおもちゃのプロジェクトです...

TDDを多用するオープンソースプロジェクトに名前を付けることはできますか?C ++が望ましいですが、JavaとC#または他の類似言語を読むことができます。


あなたの質問に答えるのは難しい。自動化されたテストを利用するプロジェクトは数多くありますが、TDDの哲学をどれだけ推進しているかはおそらくわからないでしょう。また、c ++、c#、およびjava kindaは、テストが困難なGUIアプリケーションにルーツを持っています。通常、フレームワークまたはライブラリ内でより多くのテストを見つけるでしょう。
iMacUwhAK

私は非常に良い答えを見つけることに興味を持っていた理由の一部は、私は現在、C ++エンジンとJava GUI ...とデスクトップアプリケーションに取り組んでいるということである
ザビエルNodet

回答:


19
  • JUnitは100%テスト駆動で開発されました。実際、それはJUnitで100%テスト駆動開発されました。KentBeckが数回言ったように、これは本当に気が遠くなるような作業でした。
  • SunのZFSファイルシステムはテスト駆動で開発された思います
  • 用IKJインタプリタIokeの言語自体のプログラミング言語(JVM)、Iokeプログラミング言語(CLI)、全体Iokeコアと標準ライブラリのIKCインタプリタ、実際には100%テスト駆動(実際にはビヘイビア駆動開発されました)。

DUnit-Delphiのテストフレームワークには、DUnit自体の完全なテストスイートが付属しています。そして、私はケントに同意します、それは少し心を曲げています。;-)
ニックホッジズ

14

SQLite。すべてのコードは非常に、非常に厳しくテストされています:

バージョン3.7.14の時点で、SQLiteライブラリは約81.3 KSLOCのCコードで構成されています。(KSLOCは、数千の「ソース行コード」、つまり、空白行とコメントを除くコード行を意味します。)比較すると、プロジェクトには1124倍のテストコードとテストスクリプトがあります-91421.1 KSLOC。


1
うわー、たくさんのテストがあります:|
ルカマッテイス

8
徹底的にテストされているとは、必ずしもテスト駆動(TDD)方式で開発されたという意味ではありません。でしたか?(私はそのページ全体を読みませんでしたが、ページ内検索で「TDD」も「ドリブン」も見なかったため、これに対する答えがわかりません。)
lindes

1
@lindes:彼らは厳密にTDDに従っていないようですが、例えば、すべてのバグ報告のために最初にテストを行います。また、コミットごとにテストを実行します。そのため、少なくとも部分的にはTDDです。
リオリ

9

FitNesseがTDDで書かれており、プロジェクトの主な貢献者がボブ・マーティンおじさんであるのを思い出すと、おそらく本当にきれいなコードでしょう


私はちょうどそれを見ていた、そしてそれはです本当にきれいなコード。
ロバートハーベイ

3

MicrosoftのP&Pチームとの議論から、Enterprise LibraryはTDDで作成されました。


Enterprise Library 5.0をプルダウンして、ソースコードを見ました。テストの大規模なコレクションがありますが、テストプロジェクトには多くのテストフィクスチャ、コールハンドラ、その他の複雑なオブジェクトがあります。それ自体がアプリケーションのように思えます。私はこの作品を賞賛しますが、TDDのred-green-refactorの世界観にどのように適合するかはわかりません。
ロバートハーヴェイ

@Robert-彼らが私に言ったことだけを伝えることができます...彼らはそれを書くときにTDDを使いました。
ウォルター

6
@Robert-テストスイートが独自の生活を送ることは珍しいことではありません。DRYは、アプリケーションとテストの両方に適用されます。TDDでは、テストの作成、コードの作成、テストのリファクタリング、コードのリファクタリングの4つのうち1つだけを実行します。これらすべてを赤緑リファクタリングパターンで実行している場合、TDDを実行しています。
ジェフネクト

1
@ジェフ:それを明確にしてくれてありがとう。TDDの説明方法(還元主義的、機構的用語)と、実際のシナリオでTDDが実際に使用される方法には、いくつかの違いがあると思います。
ロバートハーヴェイ

3

TDDを使用したオープンソースプロジェクトに名前を付けることはできませんが、TDDが使用された実際のプロジェクトに取り組んできたことがわかります。


1
あなたや他の人はこれらの経験を共有しましたか?良い戦争物語のように聞こえます。

私はそれについて少しツイートし、逸話を使用して他の投稿のポイントを説明しました。テストファースト設計と自動化されたテストスイートは私の人生をとても楽にしてくれると言うだけで十分です。私は戻って他の方法で開発することはありません。例:手動テストでは検出されなかった1つのテストケースの微妙なバグ(手動テスターはすべての操作後にデータベースの整合性をチェックしないため); その日、テストケースを何度も実行して、それを把握しました。これは、40時間以上の手動テスト時間の節約に相当します。最近、1000件以上のコード変更を行い、睡眠中にテストを実行しました。TDDは揺れます。
スティーブンA.ロウ

私はあなたを信じています。私はただ物語を聞きたいです。あなたはQuickCheckの興味深いを見つけるかもしれない- en.wikipedia.org/wiki/QuickCheckを -私は15歳の生産コードのバグをマルチスレッド見つかったプレゼンテーションを見ました。

「手動テスターはすべての操作の後にデータベースの整合性をチェックしないため」-制約と適切に設計されたDBスキーマはさらに揺れ動き、すぐにバグを見たのでテストに1日を費やす必要がなくなります。 。
gbjbaanb

@gbjbaanb:この場合は、「チェック」はそれのための自動テストがあります理由です、簡単なスキーマの整合性よりもはるかに複雑だった
スティーブンA.ロウに

0

TDDで完全に行われた私の最初のプロジェクトは、2002年のオープンソースプロジェクトでした。

http://sourceforge.net/projects/camelos/

現在、私は主にTDDで働いていますが、チームの全員がそうしているわけではありません。それは、一日の終わりにテストを書いていれば問題ありません。

また、コア部分にTDDを使用した完全なgwt-gaeアプリケーションも作成しました。 http://netnumero.appengine.com/company/mycompany

そのコードをリリースすることはできませんが、GWDのTDDで行われている完全なサンプルプロジェクトに取り組んでおり、UIでもTDDを使用しています。

(クリスマス休暇)終了したらすぐにここに投稿します https://github.com/ubertob/gwt-tdd-example

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.