アプリケーションを継承するときにすでに動作するコードの単体テストを書くことに価値はありますか？

明らかに、一部の古いアプリケーションは、そもそも記述された方法のために、単体テストを行うことができないか、非常に困難です。

しかし、おそらくユニットテストされる可能性のあるいくつかのヘルパーメソッドのように、それらのためにユニットテストを書くことをわざわざする必要がありますか？

つまり、それらは犬のように書くことができますが、論理が複雑に脆弱であっても、時間のテストはそれが本来の方法で機能することを証明しました。リファクタリングと言う場合にのみユニットテストを行う必要がありますか、時間があるときはいつでもユニットテストを作成する必要がありますか？

これを行うことに価値はありますか？

また、メソッドの定義が曖昧かもしれないことを考慮に入れて、特定の条件でメソッドのいくつかが実際に何をすべきかを研究する必要があるかもしれません。

できる限り多くのアプリケーションのテストを書くべきだと思います。彼らはあなたがコードベースを学び、最終的なリファクタリングや新しい開発の準備をするのに役立ちます。

このシナリオで作成できるテストにはいくつかの種類があり、それぞれにメリットがあります。これらのテストを書くことで、扱っているアプリケーションについて多くを学ぶことができます。

まず第一に、正確性のためにテストの作成を開始する前に、正しいか間違っているかにかかわらず、現在の動作をキャプチャするテストを作成します。プログラムの実行によって完全にテストされなかったコーナーケースまたはコードの一部のバグを発見するのは、かなり安全な賭けです。コードが何をすべきかを心配せずに、それが何をするかを把握してください。続行するときに、コードを読んだり、出力がどうあるべきかを理解するのに真剣に時間を費やすことを心配しないでください。テストを実行し、その出力をアサートにキャプチャするだけです。

これにより、コードがどのように動作し、主要な問題点や弱点がどこにあるかをしっかりと理解できます。バグを発見した場合は、修正する価値があるかどうかを判断する権限を持つ人々にアプローチし、それらの決定を下すことができます。

次に、簡単に単体テストできないかもしれないが、ワークフローをできるだけテストすることが重要であるコードの部分をカバーする、いくつかのより大きな（スコープ内の）テストを書くことができます。これらのワークフローテストまたは統合テストは、見方によって異なりますが、これらのワークフローをリファクタリングするための優れた基盤となり、よりテストしやすくなり、既存のワークフローに影響を与える可能性のある新しい機能を追加する必要がある場合に保護されます。

時間が経つにつれて、あなた自身またはアプリケーションを継承する次の人を支援するためのテストスイートを構築します。

私は単体テストを単なるテストではなく仕様として見ています。特定のケースでは、新しい仕様に準拠するために変更を行う前に単体テストを実施したときに、真の価値がもたらされると述べました。継承されたコードを変更する場合、私が見る最善の方法は、機能の単体テストを持つことです。これは、セーフティネットをもたらすだけでなく、その特定のユニットの動作をより明確にするのに役立ちます。また、あなたが述べたように、理解に役立ついくつかの研究をあなたに強制するかもしれません。そのため、変更を行う前に、モジュールの単体テストを実施することが私の考えです。

 > Is there any value in writing unit tests for code that 
 > already works when inheriting applications?

いいえ。私の経験から、大量のリファクタリングを行わずに単独でコードをテストする方法を見つけることは非常に考えにくい/困難であるため、製品コードの作成後に単体テストを書くための悪い費用/利益の関係があります。テスト駆動開発の利点の1つは、疎結合コードを取得できることです。後でテストを記述すると、コードが密結合される可能性が高くなります。

はい、変更する予定の機能のアプリケーションの統合テストを作成できます。このようにして、変更が何かを壊すかどうかを確認するための回帰テストを行うことができます。

YESビューの品質と開発のポイントから、テストを持っている価値があります。

ビジネスの観点からは、本当のビジネス価値を得るために時間/お金が必要であると顧客に売ることは非常に難しいが、ビジネスの変化が事態を悪化させないという漠然とした約束のために、顧客に売ることは非常に難しいため、NO。

可能な限り、「既に動作している」既存のコードのテストを作成する理由がさらにあります。テストがない場合は、コードが臭いに満ちている可能性が高く、広範なリファクタリングを使用して改善できる可能性があります。テストスイートはリファクタリングに役立ちます。元のコードが正しく動作しないことさえ明らかになるかもしれません。売上レポートを生成するメソッドのテストを書いたとき、それが正しく計算されていなかったため、売上が実際よりも数千ドル多かったことがわかりました。 （幸いなことに、それは物事の実際の財政的終わりではなく、単なる販売レポートの見積もりでした）。

もちろん、このアドバイスは、実際にテストを作成できる場合にのみ適用されます。私の経験では、テストなしでコードベースをテストすることはほとんど不可能です。なぜなら、最初にテストをサポートするためにコードモジュールの半分を抽象的に書き換える必要があり、それができないからです。

ユニットテストでは、正確性を検証するのではなく、システムの実際の動作を特徴付ける必要があるため、絶対にyesです。特にレガシープロジェクトでは、要件の多くが実際の動作に暗黙的にエンコードされます。

この特性化は、機能のベースラインとして機能します。動作がビジネスの観点から誤っている場合でも、動作がさらに悪化するのを防ぎます。レガシープロジェクトで牽引力を得ることは困難な場合があり、これによりベースラインが得られるため、事態を悪化させることなく前進できます。

それで、あなたができるすべてのユニットテストを書いてください。テストできないコードについては、コードに「継ぎ目」を導入して依存関係を分離するようにコードをリファクタリングします。テストしたくないコードからテストしたいコードを分離できる場所です。

キャラクタリゼーションテストおよびシームとしての単体テストのアイデアは、Michael Feathersによるレガシーコードを効果的に使用する際の主要なポイントです。

文書化されていない、ひどくひどく書かれたものが非常に多くありますが、システムにはレガシーコードが機能しているので、私はこのことについて考えました。

あなたは細かい点を指摘します：

リファクタリングと言う場合にのみユニットテストを行う必要がありますか、時間があるときはいつでもユニットテストを作成する必要がありますか？

要件が変更された場合、ユニットテストを書くことが最も価値があると思います。そうでなければ、適切なテストを書くことができないので、特に気にしません。なぜなら、あなたはすべての条件を知らないからです。

時間があれば？

優先順位をつける時間があるので、そうはならないでしょう。:)

これまで本番アプリケーションで使用されていなかったコードベースの側面を活用しようとしていますか？最初にそれらのシナリオの単体テストを作成します。ここでの作業に優先順位を付けることができる必要があり、その点でアートオブユニットテスト（特にレガシーコードベースのテストのアプローチ方法）にはいくつかのアドバイスがあったと思います。

アプリケーションが稼働しているという理由だけですべてが機能していると想定しないでください...通常、「時間のテスト」は、a）残りの欠陥をまだ見つけていない、またはb）見つけた人だけを示しています彼らはそれらを報告していません。（またはおそらく両方。）そして、おそらく現在動作しているコードでさえ、次に変更を加えなければならないときには動作しないかもしれません。

単体テストでは、特定の機能が損なわれていないという確実性の尺度が得られますが、合理的な量のケースでこれを実証する方法も提供されます。これは、1つのバグ修正であっても、「これを調べてテストする」よりもはるかに価値があります。（突っ込むことは、統合テストやシステムテストに相当するので、その意味で、アプリの手動テストは単体テストだけではカバーできないものですが、それでも非効率的な方法で時間を費やしています。これらのテストを自動化する方法でも手動で行うよりも優れています。）

コードを修正するときは、それが修正であろうとリファクタリングであろうと、間違いなくテストを書くべきです。次回欠陥を修正する必要があるときに時間を節約する以外の理由がない場合は、できる限りテストを作成することをお勧めします（次回もあります）...この場合は、そのソフトウェアは常に欠陥がないと偽装する人々の期待とその時間のバランスをとる必要があり、したがって将来のメンテナンスに費やされる時間は「無駄」です。（ただし、現在のスケジュールを無視する必要はありません。）ある時点で、これを行うと、十分なカバレッジが得られ、レガシーアプリケーションでのテストの価値を実証できるようになります。その時間は将来のアプリで、最終的には生産的な開発に費やす時間を解放するはずです。

私のララランドの心から、それだけでなく「はい」と言うだけでなく、それをハックし、リファクタリングし、テストを続けますが、他の重要なプロジェクトに遅れをとらないようにしてください。 働くプログラマーとして、あなたの仕事が危険にさらされている場合、またはマネージャーが所有権を取るようにあなたに言った場合、はい。チームまたは会社が苦しむ可能性がある場合は、上司と交渉して、会社を災害から守るためのテストを行う必要があることを伝えます。彼が心配しないと言うなら、あなたはフックから外れています（必ずしも、責任委任は管理スキルなので、フックから外れていることを確認してください...本当に！）

がんばろう！