話をして、ユニットテストは何をテストすべきですか?

現在、大企業はますますプロジェクトのユニットテストを重視し、プロジェクトのユニットテストのカバー率がある値を下回ってはならないことを明確に要求し、ユニットテストの重要性を十分に示している.
ユニットテストがなければ、コードが正常に動作することをどのように保証するかを考えてみましょう.
テスト担当者が行ったのは業務上の統合テスト、つまりブラックボックステストだけで、単一の方法ではテストできません.また、テストされたバグの範囲も広く、バグの範囲を確定することはできません.バグがどこにあるかを確定するのに時間がかかります.
また、最も一般的な問題は、単測を書くのに時間を浪費することですか?バグを修正する時間(位置決め+修復)を計算したことがありますか?計算すると、時間の無駄が多くなることがわかります.

リファレンス推奨

ユニットテストの書き方については、以下のいくつかのアドバイスを参考にしてください.
1.テストデータの外部化
テストデータは大きく2つに分けられます.変化するものと変わらないもの、変わらないテストデータについては、ユニットテスト用例コードに完全に書くことも、データを外部化することもできます.
一方、テストデータが常に変化し、テストデータ量が比較的大きい場合は、テストデータの外部化を用いてテスト用例の外部にデータを配置して統一管理することができる.
データの外部化とは?つまり、ユニットテスト用例の外部統一管理にデータを置くことです.例えば、ユニットテスト用例のテストデータをCSVファイルに統一することができます.
注釈@ParameterizedTestおよびCVSファイルに導入された注釈@CsvFileSourceは、例えばjunit 5のパラメータによってテストされ、その中のresources属性指定CSVファイルはnumLinesToSkip=n属性指定がn+1行目から開始される.これにより、1つのCSVファイルで1つのユニットテスト例のデータを統一的に管理することができます.
テスト例に必要なデータを管理するには、CSVファイルを1つずつ管理するだけです.
次の例を見てみましょう.(具体的な使い方はブログjunit 5シリーズ-パラメトリックテストを参照してください)

@ParameterizedTest@CsvFileSource(resources = "/two-column.csv", numLinesToSkip = 1)void testWithCsvFileSource(String first, int second) {
    assertNotNull(first);
    assertNotEquals(0, second);
}

ここでtwo-column.csvファイル内容

Country, referenceSweden, 1Poland, 2"United States of America", 3

2.特定の結果を持つテストの構築

メソッドの結果がランダムであれば、このようなメソッドはほとんどテストできないので、このメソッドについてはテストできません.

特有のデータに基づいて特定の結果を得る方法をテストするしかありません.

3.テスト面は全面的で、設計の各方面にはテスト例が必要である.

正面全情景

負のすべてのシナリオ

臨界値

特殊値

4.試験用例はできるだけ簡潔で短くしてください
テストを完了できる上でできるだけコードを簡潔にすることで、コードをよりきれいにするだけでなく、理解を維持することができます.コードの山と何行のコードを考えてみてください.どちらが見たいですか.
5.試験用例はなるべく速く
ユニットテストの使用例について、私たちはほとんど1つの方法を開発したり修正したりするたびに、私たちはほとんどテストの使用例を実行して、他のモジュールの正常な運行に影響しないことを確保します.だから、できるだけあなたのテスト方法を「早く!」ユニットテストに関係のないコードを削除します.もちろん、テストの完全性と正確性を保証することが前提です.鄭州専門不妊不妊病院:http://jbk.39.net/yiyuanfengcai/tsyl_zztjyy/3032/
6.ユニットテストを実行するたびに、100%正常に実行されていることを確認してください.
これは比較的簡単ですが、データの期限切れ、方法の内部論理の変更など、多くの原因でテスト例の失敗を招く可能性があります.
これらはあなたのいくつかの时間をかけて修正するかもしれませんが、あなたは往々にして嫌がるかもしれませんが、一つのことをした以上、一つのことをしてください.
しかし、これらの小さなエラーに注意しないと、大きなプロセスが失敗する可能性があります.私たちはプロセスを実行するときに小さなエラーがプロセスの整理に失敗することが多いことを知っておく必要があります.
7.あなたのテストを設計する
これには多くの面が含まれていますが、次のいくつかの面で注意すべきだと思います.

前述のコードは品質を保証する前提の下でできるだけ簡潔である

.

ユニットテストでは、コードの抽象化も可能であり、再利用可能なコードを抽象化し、コードの再利用性を高め、コードの重複を減らすこともできます.

テストクラスのテスト方法に良い名前を付けます.テストクラスは一般的に「クラス名+Test接尾辞」であり、どのクラスに対するテストを表すことができます.試験方法も同様で、「試験方法名+Test接尾辞」または一つの方法の一部に対して「試験方法名+試験部分作用+Test接尾辞」を試験する.鄭州不妊不妊病院はどの病院が良いですか?http://www.zzfkyy120.com/

各試験方法は被試験方法の機能的断言を多すぎるべきではなく、1つの方法が複数の断言を必要とする場合、大まかに分類することができ、2つの試験方法に分けられず、細粒度の試験を行うことができる.

8.コードオーバーライド率のテストに注意
設計されたユニットテストでは、コードテストのオーバーライド率も高く、100%のテストコードのオーバーライド率は要求されませんが、高オーバーライド率のコードが検出されていないエラーを含む確率は低く、より多くのソースコードがテスト中に実行されるためです.
注意:高コードオーバーライドはテストが完璧であることを保証できないので、気をつけてください.
9.他にもいくつかの注意点があります.例えば、

print文を使用してテスト結果を出力しないで、手動で正しいかどうかを判断し、断言

を使用します.

いくつかの理解しにくいテストは方法の上で注釈を明記したほうがよくて、後期の理解とメンテナンスに便利です

フレームワークを使用してユニットテストを行います.例えば、Junit 5のブレークスルーサポートがあなたのニーズを満たしていない場合は、ASsertJフレームワークを使用してブレークスルーを豊富にすることもできます.MockitoはMockデータなどの

を行います.
はい、上記はユニットテストをどのように書くかについてのアドバイスです.もし適切でない場合は、コメントエリアで指摘してください.感謝しています.