現在、大企業はプロジェクトの単体テストにますます注意を払っており、プロジェクトの単体テストカバレッジが特定の値を下回ってはならないことを明示的に要求しています。これは、単体テストの重要性を示しています。
単体テストがない場合、コードが正常に実行できることを確認するにはどうすればよいですか？
テスターは、ビジネス統合テスト、つまりブラックボックステストのみを行っています。単一のメソッドをテストする方法はなく、テストされるバグの範囲も非常に広く、バグの範囲を特定することはできません。時間をかけてバグの場所を特定します。
さらに、最も一般的な質問の1つ：単一のテストを作成する時間を無駄にしますか？バグの修正に必要な時間（場所+修正）を計算しましたか。それを数えると、より多くの時間が無駄になっていることがわかります。
参考提案
単体テストの記述方法について、参考のためにいくつかの提案を示します。
1.テストデータの外部化
テストデータには、変更と不変の2種類があります。変更されていないテストデータについては、単体テストケースコードに書き込むか、データを外部化できます。
テストデータが常に変化し、テストデータの量が比較的多い場合は、テストデータの外部化を使用して、データをテストケースの外部に配置し、統合管理を行うことができます。
データ外部化とは何ですか？単体テストケースの外部統一管理にデータを入れることで、例えば、CSVファイルの単体テストケースにテストデータを入れることができます。
junit5などのパラメーターを使用して注釈をテストし@ParameterizedTest、CVSファイルの注釈を導入し@CsvFileSource、CSVファイルを指定するためのリソース属性を指定できます。numLinesToSkip= n属性は、n + 1行目から開始することを指定します。これにより、単体テストケースのデータをCSVファイルで一元管理できます。
テストケースで必要なデータを管理するには、1つのCSVファイルを管理するだけで済みます。
以下はケースを示しています：（特定の使用方法については、ブログjunit5 series-parameterized testを参照してください）
@ ParameterizedTest @ CsvFileSource（resources = "/two-column.csv"、numLinesToSkip = 1）void testWithCsvFileSource（String first、int second）{
assertNotNull（first）;
assertNotEquals（0、second）;
}
その中で、two-column.csvファイルの内容
国、参照スウェーデン、1ポーランド、2 "アメリカ合衆国"、3
2.特定の結果でテストを作成する
メソッドの結果がランダムである場合、そのようなメソッドをテストすることはほとんど不可能であるため、このメソッドをテストする方法はありません。
一意のデータに基づいて特定の結果を生成するメソッドのみをテストできます。
3.テストの側面は包括的であり、設計の各側面にはテストケースが必要です。
すべての肯定的な状況
すべての否定的な状況
重要な価値
特別な価値
4.簡潔で短いものにしてください
コードは、テストの完了に基づいてできるだけ簡潔にする必要があります。これにより、コードがより美しくなるだけでなく、維持および理解されます。多くのコードと数行のコードについて考えて、どれをもっと見たいですか？
5.できるだけ早くテストケース
ユニットテストケースの場合、ほとんどの場合、メソッドを開発または変更するたびに、テストケースを再度実行して、他のモジュールの通常の動作に影響がないことを確認します。したがって、テストメソッドを「高速」にしてください。単体テストとは関係のないコードをいくつか削除します。もちろん、前提はテストの完全性と正確さを保証することです。鄭州専門不妊病院：http://jbk.39.net/yiyuanfengcai/tsyl_zztjyy/3032/
6.単体テストを実行するたびに、100％成功することを確認してください。
これは比較的単純ですが、データの有効期限切れ、メソッドの内部ロジックの変更など、テストケースが失敗するさまざまな理由があるため、実行するのはより困難です。
这些可能会花费你的一些时间去修改，你往往可能不愿意，不过既然做了一件事，就做好一件事呗
但是如果你不注意这些小错误，这可能就会导致你的一个大流程失败，大家应该知道，我们在运行一个流程时往往一个小小的错误就导致流程整理失败！
7. 设计好你的测试
这包含的方面就比较广了，下面几个方面我认为大家应该注意的：
前面所说的代码在保证质量的前提下尽量简洁
单元测试中代码的抽象也是可以有的，我们也可以将一些可重用的代码抽象出来，提高代码的重用性和减少代码的重复。
给测试类测试方法起一个好名字。测试类一般是“类名+Test后缀”，可以表示对哪个类进行的测试。测试方法也是类似，“测试方法名+Test后缀”或者对一个方法的部分测试“测试方法名+测试部分作用+Test后缀”。郑州不孕不育医院哪家好：http://www.zzfkyy120.com/
每个测试方法对被测试方法的功能断言不宜过多，如果一个方法需要多个断言进行测试，我们可以进行大致分类，将其分不到两个测试方法中，这样可以细粒度的进行测试。
8. 注意测试代码覆盖率
一个设计好的单元测试，其代码测试覆盖率也是很高的，并不要求100% 的测试代码覆盖率，但是高覆盖率的代码包含未检测到的错误的几率要低，因为其更多的源代码在测试过程中被执行。
注意：高代码覆盖不能保证测试是完美的，所以要小心！
9. 还有就是一些其他的注意点了，比如
不要使用print语句去输出测试结果人工判断是否正确，要使用断言
一些不好理解的测试最好在方法上面写明注释，便于后期理解与维护
使用框架进行单元测试，比如Junit5如果其中的断言支持不满足你的需求也可以使用ASsertJ框架来丰富断言，Mockito进行Mock数据等
好了，上述就是对如何写好单元测试的一些建议，如有不当，请在评论区中指出，感激不尽！