TDD /テストのオーバーヘッド/メンテナンスの負担が大きすぎますか？
つまり、テストの価値を本当に理解していない人から何度も聞いたことがあるでしょう。物事を始めるために、私はアジャイルとテストのフォロワーです...
私は最近、現在のチームがどのレベルでもユニットテストを実践しておらず、おそらく依存性注入手法やテストパターン/デザインなどについて聞いたことがない（製品の書き直しでTDDを実行することについて話し合いました）コードをクリーンアップします）。
今、私はこの製品の書き直しを完全に担当しており、TDDの方法でそれを試みることは単にメンテナンスの悪夢になり、チームが維持することを不可能にするだけだと言われています。さらに、それはフロントエンドアプリケーション（Webベースではない）であるため、テストを追加しても意味がありません。ビジネスドライブが変更されると（当然のことながら変更とは）、テストは古くなり、他の開発者は将来のプロジェクトはそれらを維持せず、修正するための負担などになります。
現在テスト経験のないチームのTDDは良い音ではないことは理解できますが、この場合の私の主張は、自分の練習を周囲に教えることができるということですが、さらに、TDDはより良いものになることを知っていますソフトウェア。 TDDを使用してソフトウェアを作成し、メンテナンスチームにソフトウェアを渡すときにすべてのテストを破棄する場合でも、最初からTDDをまったく使用しないよりも確実に良い方法でしょうか。
TDDを聞いたことがないチームのほとんどのプロジェクトでTDDを行うと言ったので、私は撃ち落とされました。 「インターフェース」の考え方と奇妙に見えるDIコンストラクターはそれらを怖がらせます...
TDDを販売しようとする非常に短い会話と、人々への私のアプローチについて、誰かが私を助けてくれませんか？私は通常、会社/チームにひざまずく前に非常に短い議論の時間枠を持っています。
tDDの方法でそれを試みることは、それを単にメンテナンスの悪夢にし、チームがメンテナンスすることを不可能にします。
あなたはその議論に勝つことはできません。彼らはこれを作っています。悲しいことに、あなたにも本当の事実はありません。あなたが提供する例はすべて異議を唱えることができます。
この点を明らかにする唯一の方法は、維持コストが低いコードを用意することです。
さらに、それはフロントエンドアプリケーション（Webベースではない）であるため、テストを追加しても意味がありません。
誰もがこれを言う。それも部分的に正しいかもしれません。アプリケーションが適切に設計されている場合、フロントエンドはほとんど機能しません。
ただし、アプリケーションの設計が不十分な場合、フロントエンドは機能が多すぎてテストが困難になります。これは設計上の問題であり、テスト上の問題ではありません。
ビジネスが変化するにつれて（当然のことながら改善を意味します）、テストは古くなり、将来プロジェクトに参加する他の開発者はそれらを維持せず、修正する負担が大きくなります。
これは上記と同じ議論です。
君はその議論に勝つことはできない。だから議論しないでください。
「私はこの製品のリライトについて完全に責任があります」
その場合、
とにかくテストを追加します。 しかし徐々にテストを追加します。最初にテストを作成するのに長い時間をかけないでください。少し変換します。少しテストしてください。もう少し変換します。もう少しテストしてください。
テストが機能していることを誰かが理解し、なぜうまくいくのかを尋ねるまで、それらのテストを使用します。
（C++からJavaへの）書き換えについても同じ議論がありましたが、指示されていなくてもテストを使用しました。
私は非常に早く発達していました。正確な結果の具体例を尋ね、スプレッドシートで送信しました。スプレッドシートをunittest.TestCaseに変換し（通知せずに）、これらを使用してテストしました。
ユーザー受け入れテストを行っていて、間違いが見つかったときは、受け入れテスト中に見つかった問題をカバーするために、例を含むスプレッドシートをレビュー、修正、拡張するように依頼しました。修正したスプレッドシートをunittest.TestCaseに変換し（伝えずに）、これらを使用してテストしました。
なぜあなたが成功したのか詳細にknowする必要はありません。
ただ成功する。
そのような人々を（もしあれば）実用的な観点からのみ説得し、実際の生活におけるTDDの価値を示すことができます。例えば。いくつかの最近のバグを例として取り上げ、このバグが二度と発生しない可能性があることを100％保証する単体テストの作成方法を示します。そしてもちろん、同様のバグの全体classが表示されないようにするために、さらに12個のユニットテストを記述します（そして、コード内のいくつかのより多くの休止状態のバグを明らかにする途中でさえ、誰かが知っています）。
これが短期間で機能しない場合は、TDDを実行し、ユニットテストを自分のタスクに熱心に書くだけで、これにさらに取り組む必要があります。次に、半年程度（環境で可能な場合）後にいくつかの簡単な統計をコンパイルして、さまざまな開発者によって達成されたコード/タスクのバグ率を比較します（チームメートの疎外を防ぐために分析されます）。他のコードよりもコードで見つかったバグが大幅に少ないことを指摘できれば、管理者と他の開発者の両方に販売する強力なポイントがあるかもしれません。
これらのことについて実用的である必要があります。理論的にはTDDはいいことですが、追加されたすべてのテストを更新しない限り、そこにはほとんど意味がありません。壊れたことを報告するテストを実行する必要はありません。更新されていないテストのコード！その結果、それらを実行するにはコストがかかりすぎる可能性があります。そのコードに取り組んでいる開発者はあなただけではありません。
クライアントにはテストチームがいます。まあ、テストの負担を開発者からテスターに移すことには何の問題もありません。結局のところ、それは彼らのためにあり、テストを通じてバグを見つけた場合（たぶん、多くの自動化されたテストツール）では、レベルでユニットテストを作成しても意味がありません。バグを見つけるまでに少し時間がかかりますが、テストでは実行されなかった厄介な「統合」バグが見つかります。
たぶん、これが彼らがユニットテストを気にしない理由です。
最後に、TDDは新しいものです。私が若者だったとき、テストをしたことがなく、機能するコードを書きました。ユニットテストは、一部の人々を暖かくぼんやりさせますが、それは正しいコードの必要条件ではありません。
PS。抽象化のレイヤーを批判する別の質問があり、ここではDIコンストラクターの欠如を批判しています！決心しろ ：）
開発中のバグの発見にはXがかかり、テスト中は10Xになり、配備後には100Xになることを指摘してください。特定のモジュールにTDDを実装するパイロットテストを実行できるかどうかを確認し、開発、テスト、展開、およびサポートされている他のモジュールとの比較をフォローアップします。適切なデータがあれば、TDDモジュールでコードを生成するために使用された労力がどれだけ少ないかを示すことができるはずです。幸運を。
はい、テストを維持することは負担です。それらを更新し、テストデータを更新する：これはすべてあなたの時間を吸います。
別の方法-手動でテストし、バグを修正し、コードが機能することを数秒で伝えることができない-より多くのコストがかかります。
まあテストは負担ですが持ち運ぶのはいい負担です。本番環境での問題が発生した場合や移行中に時間を大幅に節約できるような事前の作業を行うことをお勧めします。負担は少ないですが、いつでもテストしていきたいですが、その負担を担いたいです。
あなたが置くようにすべてが非常に急速に変化するので、回帰テストに使用されることを彼らに説明してください。これは、システムクロックがオンの場合にのみ呼び出される特定の関数の10,000,000実行ごとに1回発生する問題を解決するために10年前に記述されたコード行を誰かが破ったため、新しいバグが導入されたときに多くの頭痛を軽減します。クライアントとサーバーのシステムクロックの差が3分を超えています。バグのあるソフトウェアのために失う余裕のある顧客の数を尋ねてください。