この質問は以前に投稿された他の質問とかなり似ていることは知っていますが、このトピックについて適切な方法で議論したいと思います.
「明白な」例外は単体テストする必要があると思いますか?
明らかな例外とは、たとえば、ユニットのビジネスロジックにより、これらの例外が常にメソッドの先頭で他のメソッドよりも先にスローされることが明らかになっている状況で、null 引数または空の文字列または負の数による例外を意味します。手術。
つまり、クラス コントラクトの最も単純な部分に違反した後にスローする必要がある例外について話しているのです。
ご意見ありがとうございます。
絶対。あなたはそれらを「自明」と呼んでいますが、前提条件を確認することを忘れないことについて、明らかなことは何もありません。実際、私がこれまでのキャリアで目にしたコードのほとんどは、後の混乱を防ぐために、このような明らかな措置を講じていません。
これは、公共の消費や再利用などのために書かれたライブラリ コードでよく見られますが、ほとんどの開発者は、そのようなチェックを独自のコードに入れることを忘れているようです。テスト駆動環境では、このような条件のテストを行うことで、開発者はパブリック メソッドの入力パラメーターを適切に検証する必要があります。
公平を期してみましょう...別のテストを作成して緑色のバーが表示される機会があれば、私は幸せです。:)
私はいつもそのような「単純で明白な」もののテストも書いていました。
私は通常、これらのテストを含めます。TDD を使用している場合は、本番環境のコードの記述を開始するための最も単純なテストを使用でき、TDD を使用していない場合は、優れた合格テストを取得できるため、開発を開始するのに実際に適した場所です :)
はい、getter と setter の最も単純なロジックであっても単体テストを行う必要があります。リファクタリング中にそのコードが変更された場合、ユニット テストのセーフティ ネットを配置して、ミスが発生しないようにする必要があります。テストを実行すると、これらの間違いをすぐに見つけることができます。
私が getter と setter をテストしないのは、それらが単純な割り当てを行っているか、値を返すだけの場合だけです。