はい、おそらく個別のケースを書きたいと思うでしょう。なぜなら、あなたの意見は一般的に正しく、まさに適切なテストが避けるべき状況のタイプであるためです。
私の意見では、将来誰かが convertWrapper を変更して回帰を引き起こさないようにする必要があります。
単体テストでは、コードの高レベルの機能をテストする必要があります。単体テストは実装の詳細を認識せず、「契約」の条件が満たされていることのみをテストします。大まかに言うと、2 つの別々のことを行う 2 つのパブリック メソッドがあるため (要件は記述も文書化もされていないと推測されます)、2 つの別々のテストがあります。
開発者として、実装が同じであることを暗黙のうちに知っているため、テストの 1 つを削除すると、実装の詳細に関する情報がテスト領域に突然もたらされ、将来の問題や回帰が求められます。
Dave Newton が彼の回答で指摘したオプションの 1 つは、convertWrapper(ch) == getFoo((int)ch)
関連するすべてのch
. これは素晴らしい提案であり、非常に適切かもしれませんが、高レベルの要件がconvertWrapper
「と同じ値を返す」という場合に限られますgetFoo
。繰り返しますが、テストには要件が反映されている必要があります。
もちろん、検査を廃止することが法律に違反するという意味ではありません。あなたがそれをしたとしても、悪魔は必ずしもあなたの魂を主張するとは限りません(ただし、それが通常の結果であることを願うこともあります)。アプリケーションがかなり単純な場合、または関連するリスクを受け入れる意思がある場合は、単純な「@todo Test me」ドキュメント マーカーで十分に対処できる可能性があります。時々近道をするのは問題ありませんが、その影響を本当に理解し、受け入れる場合に限ります。自分自身から自分を救うことができるのは自分だけです。:)
しかし、一般的なケースでは、はい、2 つのテストです。その後、テストを「起動して忘れる」ことができ、将来作成したルールの特別な例外を覚えておく必要はありません。