誰かが (単体) テストをロジックとして使用する小さな診断用の内部 Web アプリを作成した場合、それを行う正当な理由はありますか? Nunit は、この Web サイトのどこにでも展開する必要があることに注意してください。
私は、プログラムには独自のロジックと再利用可能な部分 (利用可能な場合) を含める必要がありますが、ロジックのテストをラップするべきではないと考えています。テストは、コード ロジックの検証を目的としています。テストがコード ロジックになると言うなら、テストを検証するためにテストを書く必要があるのではないでしょうか? なぜそれが根本的に間違っているのですか？
ヒント: これらのテストをすべてつなぎ合わせて相互に関連付けているため、依存関係がなくなっている (?)。
単体テスト以外の目的で単体テスト フレームワークを使用することは、通常、最適な方法ではありません。最初に単体テストを作成して失敗することを確認するため、単体テストのテストを作成する必要はありません。それが、それらが適切に機能していることを知る方法です。単体テスト フレームワーク内で記述されたコードのテストは自明ではないと推測しています。ソフトウェアの重要な部分の診断アプリがあれば、それが正常に機能することを本当に確認したいと思います。
編集: あなたはすでに決心しているようですが、現在の戦略がおそらく他のプロジェクト メンバーにとって理想的ではない理由を説明するためのサポートが必要です。その場合は、口の中にコードを置き、別の方法で設計された小さなサンプル アプリをまとめることをお勧めします。この特定のケースで単体テスト フレームワークを利用することが設計上の決定として不適切であるとすれば、それは明らかです。
この質問TDD Anti-patters catalogを見ると、かなりのアンチパターンを犯していることがわかります。
単体テストの目的は、クラスが本来の方法でインターフェイスに従って機能することを確認することです。したがって、単体テストをテスト アプリに使用している場合、プログラム ロジックで assert を使用しているように見えます。
テストアプリが必要な場合は、それを実装してWITHユニットテストを使用してください。何かを構成したり、ユーザーとの対話を取得したりするためかもしれません。
私が見る他の理由の1つ-ユニットテストは、すべてがどのように機能するかについての仮定に従って書かれています。あなたの仮定が正しければ、テストはパスするはずです。機能の単体テストを追加すると、すべての仮定がまだそこにあることを確信できます。したがって、すべてのテストはできる限りシンプルに保つ必要があります。これが、テスト コードをテストする必要がなく、テスト アプリケーションでテスト コードを使用する必要がない理由です。
コードはコード。テストというラベルが付いているからといって、それが有用なアプリケーションでもないというわけではありません。
動作の検証をたくさん書く必要があるとします。なぜテスト フレームワークを使用するのが悪い考えなのですか? 代わりに、同じ機能を持つ新しいフレームワークを作成し、それを別の名前にする必要がありますか?
外部ビューを取得します。このアプリケーションは、特定のことを行うと主張しています。それらは正しく行われますか？確実に？維持、強化できますか？了解した？
もしそうなら、その実装でたまたまテスト フレームワークを使用することを気にする必要はありません。その動作または構造に欠陥がある場合は、批判します。
優れたテクノロジーの素晴らしい点の 1 つは、予期しないアプリケーションがあることです。