短いスプリントを考えると、スプリント内で「物事を成し遂げる」ために TDD を放棄することは受け入れられるでしょうか。
たとえば、特定の作業では、既存の実装を中心にオブジェクト モデルを設計するためにスプリントの 1/3 が必要になる場合があります。このシナリオでは、スプリントの途中など、テストなしでコードを実装することになる可能性があります (この「設計」段階で単体テストを実装すると、かなりの労力がかかり、テストは最終段階まで数回破棄される可能性があります)。 「デザイン」が定着している）。
その後、2 週間目に 1 日か 2 日を費やして、事後に単体テストや統合テストを追加します。
これは受け入れられますか？
他の方法では完了できないプロジェクトを完了することを意味する場合、プロセスをバイパスすることはほとんどの場合許容されます。プロセスはあなたを助けるためにそこにあるはずですが、あなたのプロセスが役に立たない場合は、それを使用しないでください (もちろん、最初にチームの他のメンバーと話し合った後)。
ただし、TDD をバイパスすると、正反対の結果が簡単に生じる可能性があります。バグのあるコードを記述して、出荷する必要がある直前に書き直しが必要になる可能性があります。最終テストでは、もっと早く発見すべき重大な問題が示されるため、そうする前に慎重に検討してください。
単体テストをスキップして何かを世に送り出し、幸運にもそれが機能する場合は、それを技術的負債と見なし、できるだけ早く返済する必要があります。
多くの人にとって、2 週間のイテレーションは短くはありません。私たちの多くは、1 週間の反復を行っています。Kent Beck は、毎日の展開を奨励しようとさえしています。そして、開発プロセスをクリーンアップすることには利点があり、応答性を高めることができます。
TDD の品質を下げてデータを取り出してはいけません- 後でクリーンアップするのは非常に難しく、最終的には顧客に、迅速で汚い、ハッキングされたリリースを迫られる可能性があることを教えるだけです。彼らは、結果として生成されるがらくたコードを認識しません。また、それを維持することもできません。誰かが私にそれをやらせようとしたら、私はやめます...そして、「適切にテストする時間がない」場所で働くことを拒否しました. それはうまくいく言い訳ではありません。
注: TDD について書くときは、機能テストを含めます。これらは、認識可能なユーザー ストーリーという点で顧客にとって意味のあるシナリオを実行する必要があるため、重要です。機能テストは最も重要なテストであるため、通常はストーリーの作業を開始します。「テストの顧客は、説明した内容を取得します...」他のすべてのテストは交渉の対象になる可能性がありますが、私がチームを率いるときは、少なくともストーリーごとに 1 つの機能テストを行うか、(スクラムの人々が言うように) 「完了していません!」;-)
後でテストを追加できるとは思わないでください。それを行うのははるかに困難です。(私は両方の方法で試しました - 信じてください。)システムが進化するにつれて、リファクタリングや書き直し、または一部を破棄する必要がある場合でも、実際にテストを組み込む方が安価です。
常に適切なコード カバレッジがなければ、高品質のコードを取得することはできません。
ここで重要なのは、コード テストカバレッジです。無意味な無数のテストだけでなく、壊れる可能性のあるものもカバーします。心配する必要があるものをカバーする重要なテストです。
間に合わず、それが問題である場合は、その理由を考える必要がありますか?
テストなしで何かを正確にコーディングできる場合、単体テストを使用する必要はありません。単体テストは、コードをより速く書くか、より良いコードを書くのに役立つはずです。どちらにも当てはまらない場合は、単体テストを使用しないでください。
私の経験では、適切な単体テストを作成するには、少なくともテスト対象のコードを作成するのと同じくらいの時間がかかるため、「1 日か 2 日」でテストを作成する方法を理解するのは困難です。
とはいえ、何が「許容できる」かは、多くのことに依存します。テストを宗教的な問題として扱わないでください。テストは、コードに一定レベルの信頼を与えるために存在します。検査を先に行うことで、リスクも増大していることを認識する必要があります。これが適切な場合もあれば、そうでない場合もあります。
注意が必要な 2 つの極端な点:
後でテストを書くと言って、決してそれを回避することはありません。これが「未来からの借り入れ」であり、返済しきれないほどの借金がすぐに積み重なってしまいます。
テストに必要以上の時間を費やす。非常に小さいリスクがあり、何か問題が発生した場合に予想されるコストがテストを作成するコストよりも小さい場合、それらをテストしても意味がありません。
私の考えでは、これは危険なトレードオフになる可能性があります。場合によっては受け入れられるかもしれませんが、覆すのが難しい前例を設定します. 私がどこで働いているかは知っていますが、いくつかの複雑なことについては、プロジェクトでより良いもののアイデアが頻繁に出てくる傾向があるため、最終的に適切な実装に到達するために何かを数回実装する必要がある傾向があります。
通常、不足している要件を見つけて、多くのコードを取得する前により完全な設計を最初に作成できるのは、テストを構築するときです。捨てて、ゼロからより良いものを構築します。
重要なのは、優先度の高い 1 つの作業項目と思われる新しい何かに集中するのではなく、2 週目にこれらのテストを最後までやり遂げることです。これは一部の人にとっては問題ありませんが、他の人にとっては災害、IME のレシピになる可能性があります。
何かが足りないかもしれませんが、あなたは一般的に合意された原則に従ってTDDを実行しているか、TDDカーゴカルトのように運用しています。
チーム/会社がTDDを使用することを決定し、それを維持する予定の場合は、スプリントを長くするか、2週間以内に完了する機能の量を減らす必要があります。
テストが設計を推進していないため、あなたの説明から、実際にはTDDを行っていません。単体テストを行っている場合が多いのですが、これはまだ良いことです。
基本的な質問に関しては、テストを控えることができますか? 実際には、これは (チームの) 経験だけがあなたを導くことができるものです。通常、後悔するようになりますが、まったく配信しないよりも、すぐに悪いハックをしたほうがよい場合もあります。
この「設計」段階で単体テストを実装すると、多大な労力が追加され、最終的な「設計」が決まるまで、テストは数回破棄される可能性があります。
テスト駆動設計を使用すると、最終的な「設計」に早く到達できることがわかりました。反復回数が少なくなり、多くの場合、最初のショットが最後になります。プログラムは現実性チェックなしで設計されており、その後の実装作業と使用の試みが再設計を促進するため、通常は設計の反復が必要です。TDD では、リアリティ チェックが常に行われます。マークを見逃さず、再設計する必要がないことを確認するには、これで十分です。
良いテストは、終了するのにかかる時間を2倍にします。管理チームがもっと時間がかかるとあなたに言い聞かせたら、それでは、これは実際のプロジェクトで金属が肉に当たる場所ですよね？
TDDは熱心な実践であり、テストを失敗させるのに時間を浪費し、コンパイルエラー、テストとコードをリファクタリングして死に至らしめるなどです。結局、コードのテストカバレッジが良好である限り、機能がコンパイルされて動作を開始した直後に単体テストを作成することで時間を節約できます。
コードを出荷していない場合、開発者として何の役に立つでしょうか? 最も重要なことは、ユーザーの前にコードを表示することです。それがプロジェクトを完了するためにプロセスの一部を犠牲にすることを意味する場合は、それを実行してください。CEO は、出荷ではなく TDD の実装に対してボーナスを与えるつもりはありません。
これは、技術的な決定ではなく、ビジネス上の決定です。コードは本当に機能する必要がありますか、それとも機能しているように見えるだけですか?
許容できる場合は次のとおりです。
あなたは、ほとんど誰も使っていない新製品を持っていて、営業担当者が業界のカンファレンスに行ってそのデモを行う予定です。あなたは、あなたが残したどんなバグも彼女が回避してくれると信じています。カンファレンスはあなたの製品への関心を高め、その後の 3 ～ 6 か月で売上が増加します。あなたの会社の銀行には 8 か月分の現金が残っています。
受け入れられない場合が 1 つあります。
コードは 5,000 の病院の X 線ハードウェアを制御します。新しいバージョンを展開しています。あなたは人を殺したくありません。大きな間違いを犯すと、あなたの会社は訴えられて忘却されます。
開発のスピードと品質のトレードオフがあります。それはビジネス上の決定です。それを理解してくれるマネージャーがいるといいのですが。