TDD /テストのオーバーヘッド/メンテナンスの負担が大きすぎますか？

そのため、テストの価値を本当に理解していない人から何度も聞いています。物事を始めるために、私はアジャイルとテストのフォロワーです...

私は最近、製品の書き換えでTDDを実行することについて議論しました。現在のチームはどのレベルでも単体テストを練習しておらず、おそらく依存性注入手法やテストパターン/デザインなどについて聞いたことがないでしょうコードをきれいにするために）。

現在、私はこの製品の書き換えについて完全に責任を負っており、TDDのように試してみると、単にメンテナンスが悪夢になり、チームがメンテナンスすることが不可能になると言われています。さらに、それはフロントエンドアプリケーション（Webベースではない）であるため、テストの追加は無意味です。ビジネスドライブが変化すると（当然、改善を意味します）、テストは時代遅れになります。将来のプロジェクトはそれらを維持せず、彼らが修正するなどの負担になるでしょう。

現在、テスト経験のないチームのTDDは良く聞こえないことは理解できますが、この場合の私の主張は、周囲に練習を教えることができるということですが、さらに、TDDがより良い結果をもたらすことを知っていますソフトウェア。TDDを使用してソフトウェアを作成し、メンテナンスチームに引き渡す際にすべてのテストを破棄する場合でも、TDDを最初から使用しないよりも確実に良い方法でしょうか。

TDDを聞いたことがないチームのほとんどのプロジェクトでTDDを行うことについて言及したので、私は撃downされました。「インターフェイス」と奇妙な外観のDIコンストラクターの考えは、それらを怖がらせます...

通常、TDDを販売しようとするという非常に短い会話や、人々への私のアプローチについて、誰か助けてください。会社/チームにひざまずく前に、私は通常非常に短い議論の窓を持っています。

TDDの方法でそれを試みると、単にメンテナンスが悪夢になり、チームがメンテナンスすることができなくなります。

その議論に勝つことはできません。彼らはこれを構成しています。悲しいことに、あなたも本当の事実を持っていません。あなたが提供するどの例でも争うことができます。

この点を明確にする唯一の方法は、保守のコストが低いコードを持つことです。

さらに、フロントエンドアプリケーション（Webベースではない）であるため、テストの追加は無意味です。

誰もがこれを言います。それも部分的に真実かもしれません。アプリケーションが適切に設計されている場合、フロントエンドはほとんど機能しません。

ただし、アプリケーションの設計が不十分な場合、フロントエンドの処理が多すぎてテストが困難になります。これは設計上の問題であり、テストの問題ではありません。

ビジネスが変化するにつれて（変更によって、もちろん改善を意味します）、テストは古くなり、将来プロジェクトに参加する他の開発者はそれらを維持せず、修正するなどの負担が大きくなります

これは上記と同じ引数です。

あなたは議論に勝つことはできません。だから議論しないでください。

「私はこの製品の書き換えについて完全に責任があります」

その場合、

1. とにかくテストを追加します。 ただし、段階的にテストを追加してください。最初にテストを作成するのに長い時間を費やさないでください。少し変換します。少しテストしてください。もう少し変換します。もう少しテストします。

2. 誰かがテストが機能していることがわかり、なぜうまくいくのかを尋ねられるまで、これらのテストを使用します。

リライト（C ++からJavaへ）についても同じ議論があり、テストから指示されていなくてもテストを使用しました。

私は非常に迅速に開発していました。正しい結果の具体例を求めて、スプレッドシートで送信しました。スプレッドシートをunittest.TestCaseに変換し（通知せずに）、これらを使用してテストしました。

ユーザー受け入れテストの段階で（間違いが見つかったとき）、受け入れテスト中に見つかった問題をカバーするために、サンプルを含むスプレッドシートをレビュー、修正、および拡張するように要求しました。修正したスプレッドシートをunittest.TestCaseに変換し（通知せずに）、これらを使用してテストしました。

あなたが成功している理由を詳細に知る必要はありません。

ただ成功してください。

そのような人々を（もしあったとしても）実際的な観点からのみ説得することができ、実生活におけるTDDの価値を実証します。たとえば、最近のバグを例に取り、このバグが二度と現れないことを100％確認する単体テストの作成方法を示します。そしてもちろん、クラス全体を防ぐためにさらに12個の単体テストを作成します、同様のバグのが出現するの作成します（コード内でさらにいくつかの休止中のバグを発見するかもしれません）。

これが短期間で機能しない場合は、TDDを実行し、自分のタスクで単体テストを熱心に書くだけで、この作業を長くする必要があります。次に、半年程度（環境で可能な場合）にいくつかの簡単な統計をコンパイルして、さまざまな開発者（チームメイトの疎外を防ぐためにアニメーション化）によって達成されたコード/タスクのバグ率を比較します。あなたのコードで発見されたバグが他の人よりもはるかに少ないことを指摘できれば、管理者と仲間の開発者の両方に売りたいと思うかもしれません。

あなたはこれらのことについて実用的でなければなりません、TDDは理論的には良いことですが、追加されるすべてのテストを更新しない限り、それはほとんど意味がありません-誰も壊れたと報告するテストを実行したくない更新されていないテストのコード！その結果、それらを行うには簡単にコストがかかりすぎる可能性があります。そのコードに取り組んでいる開発者はあなただけではありません。

クライアントにはテストチームがあります。まあ、テストの負担を開発者からテスターに​​移すのに問題はありません。結局のところ、それが彼らの目的であり、テストを通じてバグを見つけた場合（おそらく、自動テストツール）を使用すると、レベルで単体テストを作成してもほとんど意味がありません。バグを見つけるのに少し時間がかかりますが、テストが実行しなかった厄介な「統合」バグを見つけるでしょう。

ユニットテストを気にしないのはこのためです。

最後に、TDDは新しいものです。私が若い頃、私たちはテストを行ったことはなく、機能するコードを作成していました。ユニットテストは、一部の人々を温かく、曖昧に感じさせますが、それは正しいコードの要件ではありません。

PS。抽象化のレイヤーを批判する別の質問がありますが、ここではDIコンストラクターの欠如を批判しています！決心しろ ：）

あなたがそれを置くとすべてが非常に急速に変化するので、回帰テストに使用されることを彼らに説明してください。システムクロックがオンの場合にのみ呼び出される特定の関数の10,000,000回の実行ごとに1回発生する問題を解決するために誰かが10年前に書かれたコード行を壊したため、新しいバグが導入された場合に多くの頭痛の種を節約しますクライアントは、サーバーのシステムクロックよりも3分の差が大きいです。バグのあるソフトウェアのために失うことのできる顧客の数を尋ねるだけです。

開発コストX、テスト10X、展開100Xの間にバグを見つけることを指摘します。特定のモジュールにTDDを実装するパイロットテストを少なくとも実行できるかどうかを確認し、開発、テスト、展開、およびサポートされている他のモジュールとの比較をフォローアップします。適切なデータがあれば、TDDモジュールでコードを生成するためにどの程度の労力が費やされたかを示すことができます。がんばろう。

はい、テストを維持することは負担です。それらを更新し、テストデータを更新します。これはすべて時間の無駄です。

代わりに-手動でテストし、退行するバグを修正し、コードが機能していることを数秒で伝えることができないため、さらに多くのコストがかかります。

さてテストは負担ですが、持ち運ぶのは良い負担です。実稼働上の問題がある場合や移行中に時間を大幅に節約できるように、事前に作業を行うことをお勧めします。少しの負担ですが、常にテストを行いたいのですが、その負担を担いたいと思っています。