C# での単体テストについては、新しい機能を実装したり、新しいソリューションを開始したりするときに、その時点から単体テストを開始する方がよいという考えからポイントがわかりました。
しかし、単体テストがほとんど、またはまったく作成されていない完全なソリューションがすでに確立されている場合、十分以上の例外処理が既に行われている場合、テストのポイントは何ですか?
私はユニットテストを書いていますが、ENUMを主に使用しているため、不正な形式のデータをテスト中のものに渡すことができないという点がわかりません!
絶対にクレイジーなものを見逃していない限り..ユニットテストを統合するために古いコードに戻って時間を無駄にしていますか?
既存のコードの単体テストを作成することは、現在または将来そのコードで作業する場合に役立ちます。テストは、新しいバグを導入していないか、不本意に一部の動作を変更していないかを確認するのに役立ちます。
また、既存のコードのテストを作成すると、不明または複雑な実装の実際の機能を判断するのに役立ちます。
バグのないソフトウェアで、開発者が再び触れることはないというまれなケースでは、単体テストを追加してもおそらくあまり役に立ちません。ただし、それ以外の場合は、動作を文書化し、将来のセーフティ ネットを確立するのに役立ちます。
ああ、あなたがそれを言及したので: Usingenumsは、C# で無効な引数を渡すことからあなたを保護しません。
いいえ、既存のコードのテストを書いて時間を無駄にしているわけではありません。なんらかの方法でコードを保守している場合は、単体テストを実施することをお勧めします。
あなたの主な課題は、作業の範囲です。大量のコード本体の単体テストを作成するのは簡単ではなく、楽しいものではありません。反復的なアプローチを取ることを強くお勧めします。最初のラウンドでは、優れたクラス カバレッジを提供する単体テストに焦点を当てることをお勧めします。これは、基本的な指標であり、出発点としても適しています。
有意義なレベルのクラス カバレッジであると感じられるレベルに到達したら、コード カバレッジの他の領域に焦点を広げることができます。
NCover のようなカバレッジ ツールを使用すると、ここでいくつかの指標を提供するのに非常に役立ちます。