取るに足らないワンライナー（もしあれば）を単体テストするにはどうすればよいですか？
この便利な関数のセットを書いて、特定の簡単な1行の計算にわかりやすい名前を付けました。問題は、それらのいずれについてもテストを記述できるとは思えないことです。私が書くものは、「f()がfの本体を実行するのと同じことを返すことを確認する」だけです-これは不自然に思われます。
このような状況ではどうすればよいですか？鼻をかざして書いていいの？これらの単体テストをスキップしますか？他に何か？
場合によります...
すべてを単体テストでテストする必要があるというルールはありません。ただし、単体テストがすべてのエラーの+ 75％（以下の説明）をキャッチしているという多くの証拠があります。
私の個人的な経験では、比較的成熟したモノリスと内部統計に基づいて、ユニットテストはQAチームに到着する前に+ 75％のエラーをキャッチします。残念ながら、事例を除いては共有できません。
ただし、パブリックドメインの領域で多数の研究が行われています。文学は、効果がゼロから約50％までの一般的な範囲を持っています。
- この質問を参照
- 業界におけるテスト駆動開発の初期調査 単体テストの実践と欠陥の減少との間に有意な相関があることに注目してください。
- テスト駆動開発：実証的証拠 一般的なコード品質の向上と18〜50％の一般的な欠陥の減少を示す文献の調査。
- Microsoftでの単体テスト自動化の有効性について TDDの導入前後のいくつかのチーム。特に、ウィンドウで検出された欠陥は38％減少しました。すべてが1つの場合、それは複雑なコードベースです。また、QAチームでの欠陥検出が、些細な誤りの検出から、より重大度の高い欠陥の識別へと変化したことも強調しています。
- 単体テストとソフトウェアの品質、実証的研究結果 単体テストの効果に関するさまざまな研究について話し合います。彼らは、50％を超える欠陥削減を伴ういくつかのプロジェクトに言及しています。
ここでの問題は、リスクの種類とそれらのリスクの程度を理解することです。次に、リスクを軽減するかどうかを選択します。
単体テストは緩和の1つの形式ですが、他の方法もあります。
最初の質問：これらの1つのライナーの範囲は厳しく管理されていますか？
1つのライナーをラップした関数がクラスのプライベートメンバーである場合、ifステートメントが実装の詳細であるのと同じように、それは実装の詳細であると主張できます。この推論に従うと、クラス全体が十分にテストされていることを確認するだけで済みます。
関数が1つのライナーをラップした場合、保護されたスコープや継承などの別の場所/後で記述されたコード、または別のモジュールなどでアクセスしやすくなります。その実装の詳細を主張するのははるかに難しくなります。
- 新しいコードがテストされているとき、あなたはそれらがあなたの関数に飛び込んで訂正をしたくないでしょう。これはおそらく他のすべての使用法を壊します。
- あるいは、ローカルでエラーを補正し、関数の修正をさらに困難にします。
これは非常に壊れやすいコードベースにつながります。絶対的な悪夢と一緒に作業します。ささいな単体テストを提供することでも、物事を整然と保つのに役立ちます。
2番目の質問：検出されないバグはどのくらい危険ですか？
これが開発者ビルドスクリプトにあった場合、スコープは開発者であり、それぞれが詳細な知識を持っていて、すぐに修正でき、エラーは簡単に検出されます。それが壊れた場合でも、開発者は存続する可能性が高く、去ることはありません。
この場合、単体テストによって提供される利点は、開発が再構築されるたびにすでにカバーされていると主張できます。そして、長続きする不利な点はなく、おそらくシステムを修正する開発者が失う時間は少しあります（テスト済みの世界で壊れた場合はすでに支払われます）。
これがインストーラー/ユーザーのコンピューターにインストールされたプログラムの場合。スコープはクライアントベースであり、（一般的に）何も知らないため、修正できず、エラーが発生している場所を（もしあれば）検出できない場合があります。それが壊れた場合、顧客はソフトウェアを二度と使用しないか、サポートに多くの時間を費やす可能性があります（これは高価です）。
この場合、+ 75％のバグが検出されないことは、2〜3倍のサポートコストと評判の低下につながり、後で顧客を減らすことができます。
3番目の質問：XがXのままであることをどのように確認できますか？
1つのライナーをより適切な名前のX()に抽出すると、クリーンアップがうまくいきます。しかし、6か月後にはどうなりますか？可能性のあるnull例外、オーバーフローがあり、実装が効率的でない可能性があります。重要な行動を変えていないことをどうやって知るのですか？
要するにあなたはしません。現時点ではそれは取るに足らないことです。しかし、後でその機能は変化または拡大する可能性があります。時間をかけて（テストとして）関数の重要な動作を記録しないと、後で関数を変更したときに（間違いを犯したときに）、手遅れになるまでそのことを知らない可能性があります。
ワンライナーでもかまいません。重要なのは、それがビジネスルールかどうかです。
物事を相互に接続する退屈な構造用グルーコードは、単体テストの価値はありません。
ネガを拒否するのと同じくらい単純なビジネスルールは、たとえそれが1つのライナーであっても、ユニットテストの価値があります。