TDDでボールを転がします

私は、他の多くのチームと協力して、少なくとも15年間使用されているアプリケーションを維持および改善する開発者チームの一員です。それが最初に構築および設計されたとき、TDDは前代未聞でした。

アプリケーションはかなり安定しており、番組停止のバグに遭遇することはほとんどありませんが、平均して週に1〜2件のバグがあり、サービスの品質が大幅に低下しています。これらのバグの発見と修正には、主に指差しのために永遠にかかります。私たちが行っている唯一のテストは、インターフェイステストです。バグが修正される前にバグがどこにあるかを探すのに多くの時間を費やしているため、私と別の開発者はテスト駆動開発を提案する予定です。近々新しいオーバーホールが予定されており、新しいモジュールでほぼ完全なユニットテストを実施したいと考えています。また、レガシーである変更が必要なコード（バグ修正や機能の実装など）のテストユニットの構築を提案する予定です。 ）、ただし、問題を引き起こしていないコードのテストケースの開発に時間を費やすことはできません。

私には、これは理にかなっているようです。今月は、修正に2週間以上かかるバグがありましたが、ユニットテストが行​​われていれば、導入前に特定できた可能性があります。しかし、私たちのマネージャーにとっては、彼らはより多くのお金を使うように見えるだけです。

ユニットテストとテスト駆動開発にお金を使うことをクライアントにどのように説得しますか？単体テストのROIを示す研究はありますか？

本格的なTDDをレガシーコードに直接組み込むメンテナンスプロジェクトは非常に困難です。私がよく見たアプローチはこれです。発生するバグごとに、バグを示す自動化された非ユニットテストを作成します。「非ユニット」とは、システムの多くの部分にアクセスしたり、データベースやファイルシステムにヒットしたりできるものを意味しますが、「自動化」とは、人間の介入なしに実行することを意味します。これは、どのような場合でも回帰スイートに必要な種類のテストです。それを書くことは多くのことを成し遂げます：たとえそれが非常に粗いレベルであっても、コードをテスト可能にし、バグと関係があるかもしれないコードの集まりにあなたをさらします。非常に具体的に関連する資料。

しかし、それで終わりではありません。このテストが実行され、赤で実行されたら（コードのエラーを示しています）、時間をかけて何が問題なのかを理解してください（いずれにしても、これを行う必要があります）。ただし、まだ修正しないでください。問題だと思うものを特定したら、ユニットを作成します。その問題を実証するテスト。これで、作業できるものを手に入れました（偶然ではありませんが、テスト性をさらに高めるために少しリファクタリングする必要があったかもしれません）。バグを修正します。単体テストのパスを監視します。多分それをいくつかのエッジケースで肉付けします。その1つのユニット（2週間の時間がかかるだけのユニット）を入手してください。ここで、回帰テストを実行して、合格するのを観察します（そうでない場合は、さらに調査とユニットレベルの作業が必要です。合格するまで繰り返します）。それをすべてチェックインします。何を手に入れましたか？以前に失敗したコードの回帰テスト。以前に失敗したコードの単体テスト。失敗した作業コード。設計コードが改善されました。これは、以前よりもテストしやすくなったためです。コードベースの信頼性が向上し、

「純粋な」TDDではありません。しかし、それは結果をすばやく示し、時間の経過とともにコードの品質を向上させます。結果は、経営陣の賛同を得るために役立ちます。

私の会社では、JoelOnSoftwareの「唯一の不満」メソッドを使用して、通常、ある種の使い捨てコンソールアプリケーションを単純にハッキングするたびに、単体テストの作成を開始しました。私はより安定したリリースで物事をより速く終わらせ始め、それに気づきました。私が何をしているのかと尋ねられたとき、私は古いコードを変更したり新しいコードを書いたりするたびにTDDの使用と単体テストの作成を始めたと説明しました。私の仲間の開発者たちは好奇心を持ち始め、統合された単体テスト自体を使い始めました。レガシーコードを機能させるためのテストを書くことについては、良い議論はないと思いますが、自動化されたテストを書くほうが、コンソールハックスパゲッティを書くよりも速くて便利だと言えるなら、賢い開発者がそれに続くでしょう。高品質のソフトウェアをもたらす他の利点もそこにありますが、開発者のサインオンを取得するための鍵は、それが彼らの生活を容易にすることを示すことです。ビジネスのサインオンに関して言えば、ソフトウェアの品質が向上し、おそらく以前よりも出荷までの時間が短縮されるという事実は、それらを説得するのに十分以上のはずです。

まず、お客様のお金に付加価値のある品質に対する真摯な姿勢と姿勢を高く評価してください。そして、マネージャーとクライアントをどのように説得できるかについての私の考えは次のとおりです。

• 過去6か月間、修正していたバグのメトリックと、バグの修正にかかった最小時間、平均時間、最大時間を収集します。
• 修正またはすべてのバグについて、それらの領域をカバーする単体テストを作成してみてください。
• 作業中のバグとこれから作業するバグについては、変更を加える前であっても、それらの領域について単体テストを作成してみてください。次に、原因を特定して修正するためのコードを記述します。既存のテストケースに違反していないか確認してください。はいの場合は、ユニットテストの重要性を同僚に説明し、理解してもらいます。
• すべての開発者がユニットテストの重要性を理解したら、何日/週も続けてきた作業を継続するように依頼してください。
• 時間が経つにつれ、チームの生産性は、マネージャーと顧客の両方が生産性とコードの品質の向上率に驚かされる程度まで向上するはずです。少し時間がかかりますが、試してみる価値はあります。

別の方法があります。それは、周りで発生するアジャイル会議に参加するためにマネージャーに参加することです。それは確かに出席する価値があるはずです。

何もうまくいかないと思ったら、次に進んでください... 率直に言って、これは私がやったことです。すべてが失敗したとき、私は次に進みました;）

そして、コードを記述した後にユニットテストが実際にTDDではないことを知っていますが、それは常に最初のステップです。少なくともここではとてもよく合います。

幸運と成功をお祈りします！