TDDは複雑なプロジェクトで本当に機能しますか？

私はTDDプロジェクトで経験した問題に関してこの質問をしています。単体テストを作成するときに、次の課題に気付きました。

• モックデータの生成と維持

大きなモックデータを維持するのは難しく、非現実的です。データベース構造が変更されると、さらに難しくなります。

• GUIのテスト

MVVMとGUIのテスト機能を備えていても、GUIシナリオを再現するには多くのコードが必要です。

• ビジネスをテストする

TDDを単純なビジネスロジックに限定するとうまくいくという経験があります。ただし、テストの組み合わせ（テスト領域）の数が非常に多いため、複雑なビジネスロジックのテストは困難です。

• 要件の矛盾

実際には、分析および設計中のすべての要件を把握するのは困難です。プロジェクトが複雑であるため、多くの場合、1つのノートの要件が矛盾につながります。矛盾は、実装フェーズの後半で見つかります。TDDでは、要件が100％正しいことが要求されます。このような場合、テストの作成中に競合する要件がキャプチャされることが予想されます。しかし、問題は複雑なシナリオではそうではないということです。

私はこの質問を読みました：なぜTDDは機能するのですか？

TDDは本当に複雑なエンタープライズプロジェクトで機能しますか、それともプロジェクトタイプに実質的に制限がありますか？

大きなモックデータを維持するのは難しく、非現実的です。データベース構造が変更されると、さらに難しくなります。

偽。

単体テストでは、「大きな」模擬データは必要ありません。シナリオをテストするのに十分な模擬データが必要であり、それ以上は必要ありません。

また、真に怠laなプログラマーは、主題の専門家にさまざまなテストケースの簡単なスプレッドシートを作成するよう依頼します。簡単なスプレッドシート。

次に、怠zyなプログラマーは、スプレッドシートの行を単体テストケースに変換する簡単なスクリプトを作成します。本当に簡単です。

製品が進化すると、テストケースのスプレッドシートが更新され、新しい単体テストが生成されます。いつもやってください。それは実際に動作します。

MVVMとGUIのテスト機能を備えていても、GUIシナリオを再現するには多くのコードが必要です。

何？「再現」？

TDDのポイントは、テスト容易性のための設計（テストドライブ開発）です。GUIがそれほど複雑な場合は、よりシンプルでテストしやすいように再設計する必要があります。また、シンプルということは、より速く、より保守しやすく、より柔軟であることを意味します。しかし、ほとんど単純なほどテストが容易になります。

TDDを単純なビジネスロジックに限定するとうまくいくという経験があります。ただし、テスト（テスト領域）の組み合わせの数が非常に多いため、複雑なビジネスロジックのテストは困難です。

それは本当かもしれません。

ただし、主題の専門家に簡単な形式（スプレッドシートなど）でコアテストケースを提供するように依頼することは非常に役立ちます。

スプレッドシートはかなり大きくなる可能性があります。しかし、単純なPythonスクリプトを使用してスプレッドシートをテストケースに変換したので、それは大丈夫です。

そして。スプレッドシートが不完全だったため、いくつかのテストケースを手動で作成する必要がありました。

しかしながら。ユーザーが「バグ」を報告したとき、スプレッドシートのどのテストケースが間違っているかを尋ねました。

その時点で、主題の専門家はスプレッドシートを修正するか、何が起こるかを説明するための例を追加します。バグレポートは、多くの場合、テストケースの問題として明確に定義できます。実際、私の経験から、バグを壊れたテストケースとして定義すると、議論がはるかに簡単になります。

専門家は、非常に複雑なビジネスプロセスを説明しようとするのではなく、プロセスの具体例を作成する必要があります。

TDDでは、要件が100％正しいことが要求されます。このような場合、テストの作成中に競合する要件がキャプチャされることが予想されます。しかし問題は、これは複雑なシナリオには当てはまらないということです。

TDDを使用しないことは、要件が100％正しいことを絶対に義務付けています。一部の人々は、TDDは不完全で変化する要件に耐えることができると主張していますが、TDD以外のアプローチは不完全な要件では機能しません。

TDDを使用しない場合、実装フェーズの後半で矛盾が見つかります。

TDDを使用する場合、コードがいくつかのテストに合格し、他のテストに失敗すると、矛盾がより早く発見されます。実際、TDDを使用すると、プロセスの早い段階で、実装（およびユーザー受け入れテスト中の引数）のかなり前に矛盾の証拠を得ることができます。

いくつかのテストに合格し、他のテストに失敗するコードがあります。それらのテストのみを見ると、矛盾が見つかります。ユーザーは矛盾について議論し、目的の動作の一貫した具体的な例を作成する必要があるため、実際には非常にうまく機能します。

はい

TDDに初めて触れたのは、Linuxベースの携帯電話用のミドルウェアコンポーネントの開発でした。最終的には数百万行のソースコードになり、さまざまなオープンソースコンポーネント用の約9ギガバイトのソースコードになりました。

すべてのコンポーネント作成者は、APIと単体テストのセットの両方を提案し、それらをピア委員会によって設計レビューすることが期待されていました。誰もテストに完全性を期待していませんでしたが、すべての公開された関数には少なくとも1つのテストが必要であり、コンポーネントがソース管理に送信されると、すべてのユニットテストは常にパスする必要がありました（コンポーネントが誤って報告していたとしてもうまくいきました）。

少なくとも部分的にTDDと、すべてのユニットテストが常にパスするという主張に起因して、間違いなく、1.0リリースは予算の範囲内で驚くべき安定性を持ってリリースされました。

1.0リリース後、企業は顧客の要求により迅速に範囲を変更できるようにしたいので、彼らはTDDの実行をやめるように言い、ユニットテストに合格する要件を削除しました。トイレの品質がどれほど速く低下したかは驚くべきことでした。その後、スケジュールがそれに続きました。

私は、プロジェクトが複雑であればあるほど、TDDから得られる利益が増えると主張します。主な利点は、TDDがコードをより小さく、はるかに独立したチャンクで記述することを強制する方法の副作用です。主な利点は次のとおりです。

a）最初からのテストによりフィードバックループが非常にタイトになるため、設計のはるかに早い検証が得られます。

b）ずっとテスト範囲のキルトを構築してきたため、ビットとピースを変更して、システムがどのように反応するかを確認できます。

c）結果として、完成したコードははるかに良くなります。

TDDは複雑なプロジェクトで本当に機能しますか？
はい。すべてのプロジェクトではないので、TDDでうまく動作すると言われていますが、ほとんどのビジネスアプリケーションは問題ありません。純粋なTDDの方法で記述されたときにうまく動作しないものは、大きな問題なくATDDの方法で記述できます。

模擬データの生成と保守
小規模に保ち、必要なものだけを用意します。これは恐ろしい問題ではありません。誤解しないでください、それは痛みです。しかし、それは価値があります。

GUIの
テストMVVMをテストし、ビューなしでテストできることを確認します。これは、他のビットのビジネスロジックをテストするよりも難しいことではありません。私はコードでビューをテストしていませんが、この時点でテストしているのはバインディングロジックだけです。これは、簡単な手動テストを行うとすぐにキャッチされます。

ビジネスのテスト問題では
ないことがわかりました。たくさんの小さなテスト。上で言ったように、いくつかのケース（数独パズルソルバーは人気があるようです）は、TDDを行うのが明らかに難しいです。

TDDでは、要件が100％正しいことが要求されます
いいえ、そうではありません。このアイデアはどこから得たのですか？すべてのアジャイルプラクティスは、要件の変更を受け入れます。あなたはそれを行う前に何をしているのかを知る必要がありますが、それは要件が100％であることを要求することと同じではありません。TDDはスクラムの一般的な慣行であり、要件（ユーザーストーリー）が完全に完全ではなく、完全に定義されています。

まず最初に、あなたの言うことには実際にはTDD固有の（テスト優先+赤緑リファクタリングのサイクル）ものは何も見られないので、あなたの問題はTDDよりも一般的な単体テストに関するものだと思います。

大きなモックデータを維持するのは難しく、非現実的です。

モックデータとはどういう意味ですか？モックには、データがほとんど含まれていないことが正確に想定されています。つまり、テストに必要な1つまたは2つ以外のフィールドはなく、テスト対象のシステム以外の依存関係はありません。モックの期待値または戻り値の設定は1行で行えるため、ひどいことは何もありません。

データベース構造が変更されると、さらに難しくなります。

オブジェクトモデルに適切な変更を加えずにデータベースが変更されることを意味する場合は、ユニットテストがそのことを正確に警告します。そうでなければ、モデルへの変更は明らかに単体テストに反映される必要がありますが、コンパイルの指示があれば簡単に行えます。

MVVMとGUIのテスト機能を備えていても、GUIシナリオを再現するには多くのコードが必要です。

確かに、GUI（ビュー）の単体テストは簡単ではなく、多くの人がGUIなしでうまくやっています（GUIのテストはTDDの一部ではありません）。対照的に、Controller / Presenter / ViewModel /どのような中間層でも単体テストを行うことを強くお勧めします。実際、MVCやMVVMなどのパターンが主な理由の1つです。

TDDを単純なビジネスロジックに限定するとうまくいくという経験があります。ただし、テストの組み合わせ（テスト領域）の数が非常に多いため、複雑なビジネスロジックのテストは困難です。

ビジネスロジックが複雑な場合、ユニットテストの設計は困難です。それぞれをテスト対象のオブジェクトの1つの責任のみをテストするように、可能な限りアトミックにするのはユーザー次第です。ユニットテストは、コードに変更を加えたときにビジネスルールや要件に違反しないことを保証するセキュリティネットを提供するため、複雑な環境ではますます必要になります。

TDDでは、要件が100％正しいことが要求されます。

絶対違う。ソフトウェアを成功させるには、要件が100％正確であることが必要です;）単体テストは、要件に対する現在のビジョンを反映するだけです。ビジョンに欠陥がある場合、コードとソフトウェアも単体テストであるかどうかに関係なく、それが単体テストの重要なポイントです。明確なテストタイトルがあれば、設計上の決定と要件の解釈が透明になり、指摘が容易になります。次に顧客が「このビジネスルールは私が望んでいるほどではない」と言ったときに変更する必要があるものに指を触れます。

TDDを使用してアプリケーションをテストできない理由は、アプリケーションが非常に複雑であるためだと誰かが不平を言うのを聞いたとき、私は笑わなければなりません。代替手段は何ですか？テストサルは何エーカーのキーボードを叩いていますか？ユーザーをテスターに​​しましょうか？ほかに何か？もちろん、それは難しく複雑です。Intelは、出荷するまでチップをテストしないと思いますか？それはどのように「真っ直ぐ」ですか？

TDD（および一般に単体テスト）は、複雑なアルゴリズム、斬新なアルゴリズム、および/またはファジーアルゴリズムに関連する理由で事実上不可能であることがわかりました。私が書いている研究プロトタイプで最も遭遇する問題は、コードを実行する以外に正しい答えが何であるかわからないということです。馬鹿げた些細な場合を除いて、手で合理的に理解するには複雑すぎます。これは、アルゴリズムにヒューリスティック、近似、または非決定性が含まれる場合に特に当てはまります。私はまだこのコードが依存する低レベルの機能をテストし、健全性チェックとしてアサーションを多用しています。私の最後の手段のテスト方法は、2つの異なる実装を、理想的には2つの異なるライブラリセットを使用して2つの異なる言語で記述し、結果を比較することです。

> Does TDD really work for complex projects?

私の経験から：Unittests（モジュール/機能のテストは単独で）の場合、これらは主にあなたが言及した問題を持たないためです：（Gui、Mvvm、Business-Modell）。1つのユニットテストをフルフィルメントするために3つ以上のモック/スタブを使用したことはありません（ただし、ドメインでさらに必要になる場合があります）。

ただし、TDDがBDDスタイルのテストとの統合またはエンドツーエンドのテストで述べた問題を解決できるかどうか はわかりません。

しかし、少なくともいくつかの問題を減らすことができます。

> However complex business logic is hard to test since the number 
> of combinations of tests (test space) is very large.

これは、統合テストまたはエンドツーエンドテストのレベルで完全なカバレッジを行いたい場合に当てはまります。ユニットテストレベルで完全なカバレッジを行う方が簡単かもしれません。

例：複雑なユーザー権限を確認する

IsAllowedToEditCusterData()統合テストレベルで関数をテストするには、さまざまなオブジェクトにユーザー、ドメイン、顧客、環境に関する情報を要求する必要があります。

これらの部品のモックは非常に困難です。IsAllowedToEditCusterData()これらの異なるオブジェクトを知る必要がある場合、これは特に当てはまります。

UnittestレベルIsAllowedToEditCusterData()では、関数が知る必要のあるすべてを含む20個のパラメーターを受け取る関数などがあります。以来 IsAllowedToEditCusterData()フィールドかを知る必要はありませんuser、domain、customer、....これは簡単なテストにありました。

私が実装しなければならなかったとき、IsAllowedToEditCusterData()2つのオーバーロードがありました：

これらの20個のパラメーターを取得してから、意思決定を行う20個のパラメーターでオーバーロードを呼び出す以外の何もしない1つのオーバーロード。

（私のIsAllowedToEditCusterData()パラメーターは5つしかなく、完全にテストするには32の異なる組み合わせが必要でした）

例

// method used by businesslogic
// difficuilt to test because you have to construct
// many dependant objects for the test
public boolean IsAllowedToEditCusterData() {
    Employee employee = getCurrentEmployee();
    Department employeeDepartment = employee.getDepartment();
    Customer customer = getCustomer();
    Shop shop = customer.getShop();

    // many more objects where the permittions depend on

    return IsAllowedToEditCusterData(
            employee.getAge(),
            employeeDepartment.getName(),
            shop.getName(),
            ...
        );
}

// method used by junittests
// much more easy to test because only primitives
// and no internal state is needed
public static boolean IsAllowedToEditCusterData(
        int employeeAge,
        String employeeDepartmentName,
        String shopName,
        ... ) 
{
    boolean isAllowed; 
    // logic goes here

    return isAllowed;
}

悲しい答えは、大規模で複雑なプロジェクトには実際には何も機能しないということです！

TDDは他の何よりも優れており、ほとんどのものより優れていますが、TDDだけでは大規模プロジェクトでの成功を保証するものではありません。ただし、成功する可能性は高くなります。特に、他のプロジェクト管理分野と組み合わせて使用​​する場合（要件の検証、ユースケース、要件の扱いやすさのマトリックス、コードウォークスルーなど）。

単体テストは強制仕様であることに注意してください。これは、複雑なプロジェクトで特に役立ちます。古いコードベースにそれをバックアップするテストがない場合、誰もが何かを壊すことを恐れるので、誰も何も変更しようとはしません。

「Wtf。なぜこのコードブランチがそこにあるのかわかりません。誰かがそれを必要としているかもしれません。

テストでは、誰でも自信を持って「私は大幅な変更を加えましたが、すべてのテストはまだ合格しています」と言うことができます。定義上、彼は何も壊していません。これにより、より機敏なプロジェクトを展開できます。COBOLを維持するためにまだ人々が必要な理由の1つは、それ以来テストが一般的ではなかったためです：P

TDDが排他的に使用された場合、つまり少なくともデバッガー/ IDEでセットアップしないと、大規模で複雑なプロジェクトが完全に失敗するのを見てきました。模擬データやテストが不十分であることが判明しました。ベータクライアントの実際のデータは機密性が高く、コピーまたはログに記録できませんでした。そのため、開発チームは実際のデータを指したときに現れる致命的なバグを修正することはできず、プロジェクト全体が廃棄され、全員が解雇されました。

この問題を修正する方法は、クライアントサイトのデバッガーで起動し、実際のデータに対抗し、コードをステップ実行し、ブレークポイント、変数の監視、メモリの監視などを行うことでした。しかし、このチームは、彼らのコードは最高の象牙の塔を飾るのに適していると考え、ほぼ1年間にわたって一度もアプリを起動したことがありませんでした。それは私の心を吹き飛ばしました。

だから、すべてのように、バランスが鍵です。TDDは良いかもしれませんが、それだけに依存しないでください。

私はそう思う、テスト駆動開発は本当に機能する

2008年、Nachiappan Nagappan、E。Michael Maximilien、Thirumesh Bhat、およびLaurie Williamsは、「テスト駆動開発による品質改善の実現：4つの産業チームの結果と経験」（PDFリンク）という論文を書きました。要約：

テスト駆動開発（TDD）は、数十年にわたって散発的に使用されてきたソフトウェア開発手法です。この方法を使用すると、ソフトウェアエンジニアは、失敗するユニットテストの作成と、それらのテストに合格する実装コードの作成を1分ごとに繰り返します。テスト駆動開発は、アジャイルソフトウェア開発方法論の重要な実現プラクティスとして最近再登場しました。しかし、ほとんどの経験的証拠は、産業的文脈におけるこの慣行の有用性を支持または反論していません。ケーススタディは、TDDを採用したマイクロソフトの3つの開発チームとIBMの1つの開発チームで実施されました。ケーススタディの結果は、TDDプラクティスを使用しなかった同様のプロジェクトと比較して、4つの製品のリリース前の欠陥密度が40％〜90％減少したことを示しています。主観的に、

2012年、Ruby on Rails開発プラクティスはTDDを想定しています。個人的には、テストとモックの作成にはrspec、オブジェクトの作成にはfactory_girl、ブラウザの自動化にはcapybara、コードカバレッジにはsimplecov、これらのテストの自動化にはguardなどのツールに依存しています。

この方法論とこれらのツールを使用した結果、私はNagappanなどに主観的に同意する傾向があります。

予算、要件、およびチームスキルの組み合わせが、「ここに参入するすべての人が希望を捨てる」というプロジェクト空間の象限にある場合、定義上、プロジェクトは圧倒的に失敗します。

おそらく、要件は複雑で不安定であり、インフラストラクチャは不安定で、チームは若くて離職率が高いか、アーキテクトはばかです。

TDDプロジェクトでは、この差し迫った障害の症状は、テストをスケジュールどおりに記述できないことです。あなたは、唯一の「取るために起こっていることを発見してみてください、これを長い間、我々は唯一持っていることを」。

他のアプローチは、失敗すると異なる症状を示します。最も一般的には機能しないシステムの配信。政治と契約は、それが望ましいかどうかを決定します。

TDD一見苦痛に思えるかもしれませんが、長い目で見れば親友になりますTDD。長い目で見れば、アプリケーションのメンテナンスと安全性が本当に向上することを信じてください。