実稼働中の既存プロジェクトにユニットテストを追加することを強く検討しています。これは、TDD のメリットを実際に理解できる 18 か月前に開始されました。（顔面を手で覆う）、今ではかなり大きなソリューションで、多数のプロジェクトがあり、どこからユニットテストを追加すればいいのか全くわかりません。私がこれを考えるようになったのは、時々古いバグが再び現れたり、バグが修正済みとしてチェックインされたりすることが時々あるからです。本当に修正中です。ユニットテストを行うことで、これらの問題の発生を軽減または防止できます。
読むことによって似ているSO の質問では、バグ トラッカーから始めて、バグごとにテスト ケースを記述して回帰を防ぐなどの推奨事項を見ました。ただし、最初から TDD を使用していれば含まれていたはずの全体像がわからなくなり、基本的なテストが欠落してしまうのではないかと心配しています。
既存のソリューションを確実に適用するために遵守すべきプロセスや手順はありますか？きちんとユニットテストは行われ、ただ詰め込まれたものではないのか？テストが良質であり、単なるケースではないことをどのように保証できるのか？いかなるテストでも、テストをしないよりはましである。
つまり、私が尋ねているのは次のことだと思います。
- すでに運用されている既存のソリューションに労力をかける価値はあるでしょうか?
- このプロジェクトのテストは無視して、将来の書き直しのときに追加したほうがよいでしょうか?
- 数週間かけてテストを追加するのと、数週間かけて機能を追加するのとでは、どちらがより有益でしょうか?
(もちろん、3 番目のポイントに対する答えは、経営陣と話しているのか、開発者と話しているのかによって完全に異なります)
賞金の理由
懸賞金を追加して、それが良いことだという私の既存の疑いを確認するだけでなく、反対する正当な理由も確認する、より幅広い回答を引き付けようとします。
私はこの質問を賛否両論とともに後で書き、製品の今後の開発を TDD に移行するために人的時間を費やす価値があることを経営陣に示すつもりです。私はこの課題に取り組み、自分の偏った視点なしに推論を展開したいと思っています。
ベストアンサー1
私は、これまでユニット テストがなかったコード ベースにユニット テストを導入しました。私が関わった最後の大きなプロジェクトでこれを行ったときは、私がチームに加わった時点では、製品はすでに実稼働中で、ユニット テストはゼロでした。私が去った 2 年後には、230,000 以上の実稼働 LOC (リアルタイム金融 Win-Forms アプリケーション) のコード ベースで、約 33 % のコード カバレッジを達成したテストが 4,500 件以上ありました。これは低いように聞こえるかもしれませんが、結果としてコード品質と欠陥率が大幅に改善され、士気と収益性も向上しました。
It can be done when you have both an accurate understanding and commitment from the parties involved.
First of all, it is important to understand that unit testing is a skill in itself. You can be a very productive programmer by "conventional" standards and still struggle to write unit tests in a way that scales in a larger project.
Also, and specifically for your situation, adding unit tests to an existing code base that has no tests is also a specialized skill in itself. Unless you or somebody in your team has successful experience with introducing unit tests to an existing code base, I would say reading Feather's book is a requirement (not optional or strongly recommended).
Making the transition to unit testing your code is an investment in people and skills just as much as in the quality of the code base. Understanding this is very important in terms of mindset and managing expectations.
Now, for your comments and questions:
However, I'm concerned that I'll end up missing the big picture and end up missing fundamental tests that would have been included if I'd used TDD from the get go.
Short answer: Yes, you will miss tests and yes they might not initially look like what they would have in a green field situation.
Deeper level answer is this: It does not matter. You start with no tests. Start adding tests, and refactor as you go. As skill levels get better, start raising the bar for all newly written code added to your project. Keep improving etc...
Now, reading in between the lines here I get the impression that this is coming from the mindset of "perfection as an excuse for not taking action". A better mindset is to focus on self trust. So as you may not know how to do it yet, you will figure out how to as you go and fill in the blanks. Therefore, there is no reason to worry.
Again, its a skill. You can not go from zero tests to TDD-perfection in one "process" or "step by step" cook book approach in a linear fashion. It will be a process. Your expectations must be to make gradual and incremental progress and improvement. There is no magic pill.
The good news is that as the months (and even years) pass, your code will gradually start to become "proper" well factored and well tested code.
As a side note. You will find that the primary obstacle to introducing unit tests in an old code base is lack of cohesion and excessive dependencies. You will therefore probably find that the most important skill will become how to break existing dependencies and decoupling code, rather than writing the actual unit tests themselves.
Are there any process/steps that should be adhered to in order to ensure that an existing solutions is properly unit tested and not just bodged in?
Unless you already have it, set up a build server and set up a continuous integration build that runs on every checkin including all unit tests with code coverage.
Train your people.
どこかから始めて、顧客の視点から進歩しながらテストを追加し始めます (以下を参照)。
コード カバレッジを、運用コード ベースのどの程度がテスト中であるかのガイド リファレンスとして使用します。
ビルド時間は常に高速である必要があります。ビルド時間が遅い場合は、ユニット テスト スキルが遅れています。遅いテストを見つけて改善します (製品コードを分離し、個別にテストします)。適切に記述されていれば、数千のユニット テストを簡単に実行でき、10 分以内にビルドを完了できます (テストあたり 1 〜数ミリ秒は適切ですが、非常に大まかなガイドラインであり、リフレクションを使用するコードなど、いくつかの例外が適用される場合があります)。
検査して適応します。
テストが高品質であり、単にテストがまったくないよりはましという状況にならないようにするには、どうすればよいでしょうか。
あなた自身の判断が現実の主な情報源でなければなりません。スキルに代わる基準はありません。
そのような経験や判断力がない場合は、そうした能力のある人と契約することを検討してください。
大まかな二次指標としては、総コード カバレッジとビルド速度の 2 つがあります。
すでに運用されている既存のソリューションに労力をかける価値はあるでしょうか?
はい。カスタム構築されたシステムやソリューションに費やされるお金の大部分は、生産開始後に使われます。品質、人材、スキルへの投資は決して時代遅れになるべきではありません。
このプロジェクトのテストは無視して、将来の書き直しのときに追加したほうがよいでしょうか?
人材とスキルへの投資だけでなく、最も重要な総所有コストとシステムの予想寿命も考慮する必要があります。
私の個人的な答えは、ほとんどの場合「もちろんそう」です。なぜなら、それがはるかに優れていることを知っているからです。ただし、例外があるかもしれないことは認識しています。
数週間かけてテストを追加するのと、数週間かけて機能を追加するのとでは、どちらがより有益でしょうか?
どちらでもありません。機能面で進歩を遂げている間に、コード ベースにテストを追加するというアプローチを取る必要があります。
繰り返しになりますが、これは人材、スキル、そしてコードベースの品質への投資であり、そのため時間が必要です。チーム メンバーは、依存関係を解消する方法、ユニット テストの書き方、新しい習慣の習得、規律と品質意識の向上、ソフトウェアの設計の改善方法などを学ぶ必要があります。テストの追加を開始するときには、チーム メンバーがこれらのスキルをそのアプローチを成功させるために必要なレベルにまだ達していない可能性が高いため、進捗を止めて大量のテストを追加することに時間を費やしてもうまくいかないことを理解することが重要です。
また、ある程度の規模のプロジェクトで既存のコード ベースにユニット テストを追加することは、コミットメントと粘り強さを必要とする大規模な作業です。根本的な変更を行い、その過程で多くの学習を期待し、ビジネス価値の流れを止めてスポンサーに ROI を期待しないように依頼することはできません。それはうまくいきませんし、率直に言って、うまくいくべきではありません。
Thirdly, you want to instill sound business focus values in your team. Quality never comes at the expense of the customer and you can't go fast without quality. Also, the customer is living in a changing world, and your job is to make it easier for him to adapt. Customer alignment requires both quality and the flow of business value.
What you are doing is paying off technical debt. And you are doing so while still serving your customers ever changing needs. Gradually as debt is paid off, the situation improves, and it is easier to serve the customer better and deliver more value. Etc. This positive momentum is what you should aim for because it underlines the principles of sustainable pace and will maintain and improve moral - both for your development team, your customer and your stakeholders.