テスト駆動開発は誰が行うのですか？

私は過去4年半にわたってエンタープライズの分野で働いてきましたが、一般的に言って、エンタープライズはテストファーストスタイルの開発を促進する環境ではないことに気付きました。プロジェクトは通常、固定コスト、固定タイムライン、およびウォーターフォールスタイルです。ユニットテストが行​​われたとしても、通常はQAフェーズでの開発後に別のチームによって行われます。

企業で働く前に、私は多くの中小企業に相談しましたが、テストファーストスタイルの開発プロジェクトにお金を払うつもりはありませんでした。彼らは通常、開発をすぐに開始するか、短い設計期間の後、つまりアジャイルに似たものを望んでいましたが、一部のクライアントはすべてがウォーターフォールのようにマッピングされることを望みました。

テスト駆動開発は、どのタイプのショップ、企業、クライアントで最も効果的ですか？どのタイプのプロジェクトがTDDを助長する傾向がありますか？

私が書くコードのすべての行は、テスト駆動開発を使用しています。経営陣が最初にテストを書いていない場合は、経営陣にそのことを伝えません。テスト駆動開発はより良いプロセスだと強く感じています。

私の上司はこれについて今日良いものをくれました、私は彼が誰かからそれを盗んでいたように私はそれを盗むつもりだと思います。

「大工がカットする前にボードを測定することを期待しますか？」

私は高校でウッドショップのクラスを取り、学校を通して建設をしました。私たちのマントラは常に「2度測定、1度切断」でしたが、それに続いて皮肉な「私はそれを切断し、再度切断しましたが、それでも短すぎました！」

後でテストする場合、作成するコードはテストが困難になるため、リワークを作成します。最初にテストするとき、または途中でテストするだけで、コミットする前に作成するソフトウェアをテストする方が簡単です。生産コードがチェックリストを満たすために記述された後に単体テストを作成する企業は、労力を浪費しています。

また、既存のテスト困難なソフトウェアとの統合により、光沢のある新しいテスト駆動型コードが消費する依存関係を制御できるようにテストシームを作成する必要があるため、さらなる労力がかかります。グローバルステートオブジェクトとゴッドオブジェクトを多用するフレームワークなどの場合、これを実現するのは非常に困難です。テスト駆動開発の難しさは、多くの場合、経験不足と適切なテストの作成、および密結合コードのテスト試行との組み合わせにあります。

ウォーターフォールプロジェクトでもドライブコードをテストできます。これは、プロジェクト管理手法ではなく、エンジニアリングの分野です。

私はTDDファンではありませんが、ソフトウェア設計について多くのことを教えてくれます。

これは独特の.Netフレーバーを持っているので、ご容赦ください。

テストファーストアプローチの対象となるプロジェクトの種類に関しては、次の点に注意してください。

• 既存のコードベースを扱っていますか？多くの場合、テストスイートを改造するのは法外に費用がかかります。継承された技術的負債がどれだけあるかを把握します
• 特定のプラットフォームとフレームワークは、本質的にテストに対応していません。私の心に焼き付けられている最近の経験-たとえば、SharePointはTDDにとって非常に難しい（しかし不可能ではない）。このようなものについては、TypeMockが役立つような市販のアイソレーター製品に頼らなければならない場合があります。
• 特定の実装アプローチは、他のアプローチよりもTDDに適しています。たとえば、コードビハインドを使用したASP.Net-それほどテストできません。ASP.Net MVC-テスト可能。コードビハインドを備えたSilverlight-あまりテストできません。MVVMを使用したSilverlight-テスト可能。

最終的に、「組織」はテストファーストへの移行をサポートするために多くのことを行うことができますが、発生する必要がある重要なシフトは開発者の心の中にあります。私は「最初にthinのテストを書く」アプローチをあきらめ、代わりに教えられる瞬間を探しました。

mgmtに問題がある場合にmgmtに通知しないことについてのmpenrowのコメントに対する+1：p

あなたの状況はすぐには変わりません。それを実現するための鍵は、それをあなたの個人的な規律の一部にして、他の人にそれをプッシュしようとする前にそれを上手くすることです。あなたがそれが機能している例になれるなら、あなたのマネージャーは客観的な利益を見るべきです。

良いビジネスケースを作成することもできます。

• TDDは、「システムが自動的に自身を検証できる仕様」として簡単に要約できます。別のプログラミングではなく、別の製品を構築するわけでもありません。

• 単体テストは、実際には単なる自動テストの形式です。これは、会社が肉スペースエンジニアに手作業で支払う可能性が高いことを、コンピューターに実行させるだけです。自動化されたテストはより速く、より一貫して実行され、適切に記述されている場合は、問題の迅速かつ簡潔で正確なフィードバックと説明および指示を提供します

• TDDは、自分が何をしているのかを知っている人によって実行されると、コードファーストと同じ速さで結果を生成します。学習/トレーニングカーブがあります（また、エンジニアが人材プールの近端から来ている場合、TDDをプッシュする可能性を完全に失う可能性があります。この場合、できることはチャンピオンを続けることです。TDDではなく経営者に質問させます）

• TDDは、タスクを開始する前に手元のタスクを熟考することを非常に重視しています。これは、「2回測定して1回カット」という行に沿ったものです。余分な測定により、タスクにわずかな時間が追加されますが、最も貴重なリソースを破棄することはありません（開発時間）。

...そして覚えておいてください。あなたができる最も重要なことは、模範を示すことです。TDDが苦手な場合は、より良くなるために余分な時間を費やしてください。習熟したら、仕事でそれを始めてください（あなたのマネージャーはあなたがテストを書いていると本当に文句を言うでしょうか？）一度に1戦ずつ戦い、それに向かって一歩を踏み出してください。シバン全体に行くと失敗する可能性が高く、それを強く押した場合、責任はあなたにかかります。

私がやります。私の好みの開発方法であり、締め切りに間に合い、高品質のコードを作成する限り、自分が納得のいく方法で作業できることを喜んでいる大規模な金融会社で働いています。正しく行われれば、テストファースト開発は開発後のテストよりも長くかかる必要はなく、システムテストからのより少ない欠陥のテストファースト開発の他の見返りを後で忘れないでください。

TDDを実行するための鍵は、コードの作成の一部としてそれを実行することです。必要に応じて、それを実行している人に伝えないでください。 あなたがしていることすべてを説明する必要はありません。最終結果は作業コードです。

「私はテストを書いています」と説明すると、The Powers That Beは「ああ、私たちはそれを排除できる！」と言うことができます。しかし、誰にも言わない場合、テストはコーディングプロセスの残りとして残っています。

プログラミングは、作業ステートメントをエディターに入力するだけではありません。人々がそれを処理できない場合、それを処理する準備ができるまで、この真実から彼らを保護します。この場合の「準備完了」とは、完成したプロジェクトが1つまたは2つ完了し、確実で信頼性の高いコードで時間通りに完了したことを意味します。

悲しいことに、私は真に古典的なテストファースト感覚でそれを使用する機会を得ていないので、「私！私！私はやる！」とは言えません。私は、「誰がTDDを日常生活に忍び込ませることができるのか」ではなく、「どの業界/企業がTDDを全面的に使用しているのか」を問いかけていると思います。私は、個々の開発者がグループ全体に強制することなく完全にTDDを実行できることに同意します。それが問題のポイントではなかったと思います。

業界について聞いたときの印象は、次のような状況では、会社のほとんどの開発グループでTDDを見る可能性が高いということです。

• TDDの開始前には、大きな既存のコードベースはありません。

• 同社は巨大ではないため、「私たちは常に他の方法でそれをやってきました」という多くの反論はありません。

• 同社は、正式なプロセスに大きな賛同を得ていません。たとえば、CMMI認定企業にTDDを実装できなかったというわけではありませんが、TDD以外のプロセスがある場合、CMMIで監視するすべてのプロセスを更新することは大きな投資になる可能性があります。

• テストはスクリプト化できます-これは最も複雑なコードベースです。ユーザーに最も近いレイヤーを簡単にスクリプト化できない場合でも、内部の一部をスクリプト化できるからです。しかし、テストのフィードバックを必要とする一連のテスト全体を再実行し、壊さないことに基づいているため、テスト自動化のための十分に開発されたオプションがある状況をTDDの最も良いスポットと考えています。私の考えでは、スタンドアロンWebアプリは良いTDDターゲットであり、主要なCOTS統合またはGUIベースではない入力を備えたシステムは扱いにくいかもしれません。

• 非プロトタイプ状態のシステム。理想的には、プロトタイプの後の次の大きなバージョン-概念実証が終了し、プロジェクトに資金が提供されますが、次の試みは品質を向上させる必要があることを誰もが知っています。

• プロセスに投資されている利害関係者。

私は可能な限り試しましたが、それは本当にあなたが自分を見つける企業環境にあると思います。私はゲーム業界で長年（アーティストとして）働いていましたが、TDDの概念はありませんでした-ただの総当たりQAアプローチです。私はWeb開発に移りましたが、ユニットテスト/ TDDの正式な認定（または知識）を備えた代理店で働いたことはありません。同じことが、幅広い分野で働く同業他社のほとんどにも当てはまります。

営業に特化した代理店では、TDDは顧客に短期の ROIをほとんど提供しないため、プロジェクトをスコーピングする際にラインマネージャーに販売することは困難です。しかし、プロジェクトが大きくなればなるほど、説得力が増します。

死の行進のような本は一般的な現象、つまり「クランチ」と「マイルストーン」主導の開発に悩まされている業界を指していることを考えると、TDDは多分、資金のあるスタートアップやモノリシックなエンタープライズショップ以外ではまれだと思います。そこにいる人々がTDDの価値を信じていないわけではありませんが、抽象的すぎて顧客に売ることができません。

私は自分でTDDになろうとしています。あなたがすでに知っているルート（日々の仕事）に従う限り、それはかなり簡単だと思います。しかし、UIパーツのテストや、これまでに遭遇したことのない問題の新しい解決策を考え出す必要があるときは、頭を包み込むことができません。または、知らないフレームワークを使用します。

だから私はあなたが何らかの種類のLearningTests、別の概念実証とその後の書き換えなどをしなければならないと思いますか、私は間違っていますか？

そして（私はそれが古いものであることを知っていますが、まだ良い答えを見ていません）：TDDを使用してアルゴリズムをどのようにコーディングしますか（結果が本当に簡単に「アサート」するのが複雑な場合）？

TDDとIMのポジティブな側面を実際に見ることができますが、初心者がコードを書くのに2倍の時間がかかるのは非常に難しいです（そして、プロをまったく見ず、あなたをm笑する仲間がいます） RADを使用）

私は数回試してみましたが、うまくいきました。残念ながら、ほとんどの場合、手動でアプリをテストできる場合は、他の何かを実装するのが退屈に感じるか、簡単に修正できないバグが出るまでユニットテストを延期します。

私がやる。ユーザーストーリーの進捗状況は、「テストがありますか？」というカンバンボードで追跡されます。開発の左側（上流）の列。

このやや珍しいレイアウトにより、1つのポリシーが明確になります。失敗した自動受け入れテスト（通常、それらのいくつか）が存在する必要があります。顧客の要件にトレーサブルでなければなりません。受け入れテストは、ストーリーカードで始まる会話の結果である満足の条件から生じます。要件をブレインストーミングし、ギャップを特定し、合格したときにユーザーの価値が提供されることを確認する主要な受け入れテスト（doneの定義）を見つける定期的なワークショップを促進します。これは、プログラマー、ビジネスアナリスト、そして時にはテスターが関与する共同作業です。

受け入れテストのフィードバックループはやや長いものです。ストーリーを完了するには数日かかる場合があります。開発には、独自の短いTDDフィードバックループがあります。

「[...テストファーストスタイルはありません...]アジャイルに似ています...」

これはアジャイルの完全な不実表示です。 doneの定義はアジャイルの重要な要素であり、その柱の1つは自動化された受け入れテストです（上記で説明したことはそれを行う1つの方法です）。アジャイルの実装方法としてエクストリームプログラミング（XP）が使用される場合、 ATDD / BDDおよびTDDが規定されています。

私はそうしますが、一般的には非UIコンポーネントのみで、一度にモジュールのアルゴリズム全体を頭に入れられないことがわかっている場合、またはモジュールが作業中のシステムの新しい部分である場合、そのため、使用しているライブラリの大部分に依存せずに高度にデバッグされています。

基本的に、要件の複雑さが原因でコードが失われる可能性がある場合に実行します。

開始するのは難しい習慣であり、管理者の賛同を必要としますが、テストが開発の途中で中断し始めると、命を救うことができます！

この質問をして、実際にTDDを実践している企業の数を確認したいと思いました。

11年間でプロとしてプログラミングを行ってきたのは、最後の2つの組織だけがTDDに気づいていました（それはほぼ5年前のことで、それ以前はTDDは今日ほど人気が​​ありませんでした）。私は、TDDのセールスピッチに脱線する前に、追跡してあなたの質問に答えます。

私が働いていた最後の会社（人文科学および科学コレクションのオンライン学術出版社）で、TDDを実践する必要があることはわかっていましたが、そこまで到達できませんでした。私たちの防御では、250kのコードベースがあったので、そのサイズのテスト不能なコードベースにテストを追加すると、克服できないと感じました（今ではタイピングをしていると感じています！）。最高の人ですら間違いを犯します。

ほんの少しのTDDを行った人なら誰でも、ブラウンフィールドのテスト不可能なコードへのテストの改修がどれほど苦痛かを知っています...主な原因は暗黙的な依存関係です（コードから結果をアサートするためにすべてのレバーを引くことはできません-モックできません）シナリオ）および単一の責任原則の違反（テストは複雑で、不自然で、セットアップが多すぎて理解しにくい）。

リリース前にプラットフォームをテストするために、 QAチームを一時的に（1人、2人から6人以上に）成長させました。時間的にも経済的にも非常に費用がかかり、一部のリリースでは「テスト」を完了するのに3か月かかります。それでも、私たちは問題を抱えて出荷していることを知っていました。それらは「ブロッカー」や「クリティカル」ではなく、「高優先度」でした。

長年の商業経験があれば、すべての会社が重要なタスクを主張し、それより高い優先度レベルを発明し、おそらくそれよりも高い優先度レベルを発明することを感謝します-特に上から誰かが機能/バグ修正をプッシュしている場合。私は脱線します...

現在の会社（通信、ウェブ、モバイルアプリの開発会社）でTDDを実践していることを報告できて、Jenkins CIと組み合わせて他の静的分析レポートを提供します（テストスイートパスをアサートした後、コードカバレッジが最も役立ちます） 。TDDを使用したプロジェクトは、支払いシステムとグリッドコンピューティングシステムです。

セールスピッチ...

多くの場合、自動化されたテストを非技術的なチームメンバーに正当化するのは困難です。テストを作成すると、開発プロセスにより多くの作業が追加されますが、...今テストに投資する時間は、後でメンテナンスの労力を節約できます。あなたは本当に時間を借りているだけです。製品の使用期間が長くなればなるほど、節約量は大きくなります。これにより、大幅な書き換えを回避できます。

最初にテストするということは、最初に意図をコーディングし、次にその意図をコードが満たしていることを確認することを意味します。これにより、フォーカスが提供され、意図したものだけを実行するコードが抽出されます（肥大化することはありません）。同時に実行可能な仕様とドキュメントです（テストが適切に記述されていて、テストがシステムコードと同じくらい読みやすい/きれいでなければなりません！）。

非プログラマーは（多くの場合）この洞察を持たないため、TDDは彼らにとってあまり価値がなく、以前のリリース日への使い捨てのショートカットと見なされます。

プログラミングは私たちの領域であり、私の考えでは、これは専門家として、TDDのようなベストプラクティスについて助言することを私たちの責任にします。プロジェクトマネージャーが開発時間を短縮するために行われたかどうかを判断するのではなく、管轄外です。同じ方法で、どのフレームワーク、キャッシュソリューション、または検索アルゴリズムを使用するかを教えてくれません。自動テストを採用すべきかどうかを教えてはいけません。

で私の意見（全体的に）ソフトウェア開発業界は、現在お使いのソフトウェアのテストを持つことは当たり前ではないという事実を破られます。

医療、航空、自動車、化粧品、ぬいぐるみ、アルコール飲料など、他の業界でこれを想像してください。私は婚約者に、製品をテストせずにできなかった業界を挙げてもらいました。

おそらく、テストが行​​われないためにテストが行​​われないと言うのは不公平かもしれませんが、自動化されたテストを行わない企業では、非常に手動/人間的な（不格好でエラーが発生しやすい）プロセスです。

あなたの質問で私が争う1つのポイント...

彼らは通常、開発をすぐに開始するか、短い設計期間の後に開始することを望んでいました。アジャイルに似ています。

「アジャイル」であることは、テストなしで進行することを規定していません。agilemanifesto.orgにリストされている最初のメンバーは、XPおよびTDDの作成者であるKent Beckです！

TDDに興味がある場合、または単に読んでおらず、熱心なプログラマーである場合（これを読んでいる人は誰ですか？;）

テストに導かれたオブジェクト指向ソフトウェアの成長

クリーンコード-ロバートCマーティン（「ボブおじさん」）シリーズ

これらの2冊の本は互いにほめ合い、多くの感覚を数ページに凝縮します。

この質問をしてくれてありがとう:)

クローンを実装する人。既存のプログラムとまったく同じように機能する、何かを開発する場合のより良いプロセスは考えられません。

明らかにこれは非常に珍しいケースですが、SQLiteの開発者はテストを広く使用しています。（定かではありませんが、開発プロセスはテストファーストだと思います。）

• 73,000行のコード
• 91,378,600行のテストコード

http://www.sqlite.org/testing.htmlを参照してください