この記事は、「ユニットテストの原則」という本の概要です。
良い単体テストのプロパティをリストすることから始めましょう。
最初。開発サイクルに統合されています。積極的に使用するテストのみが役立ちます。そうでなければ、それらを書くことは意味がありません。
第二に。コードの最も重要な部分のみがテストされます。すべての動作するコードが同じ注意に値するわけではありません。
第三。最小限のメンテナンスコストでバグに対する最大限の保護を提供します。これを行うには、効果的なテストを認識して書き込むことができる必要があります。
ただし、効果的なテストを認識して作成することは、2つの異なるスキルです。そして、2番目のスキルを習得するには、最初に最初のスキルを習得する必要があります。この記事の残りの部分では、効果的なテストを認識する方法を説明します。「ブラックボックス」/「ホワイトボックス」の原則に従ったテストとテストのピラミッドも考慮されます。
優れた単体テストの4つの側面
優れた単体テストには、バグ保護、リファクタリング耐性、迅速なフィードバック、およびメンテナンスの容易さという属性が必要です。
これらの4つの属性は基本です。これらは、ユニットテスト、統合テスト、エンドツーエンドテストなど、あらゆる自動テストの分析に使用できます。
優れた単体テストの最初の属性であるバグ保護から始めましょう。バグ（またはリグレッション）はソフトウェアのバグです。原則として、このようなエラーはコードに変更を加えた後に発生します。
機能が多いほど、新しいバージョンにバグを追加する可能性が高くなります。これが、優れたバグ保護を開発することが非常に重要である理由です。このような保護がなければ、エラーの数が絶えず増加するため、プロジェクトの長期的な成長を保証することは不可能または非常に困難になります。
バグ保護の観点からテストがどの程度うまく機能するかを評価するには、次のことを考慮してください。
テストによって実行されたコードの量。
このコードの複雑さ。
ビジネスロジックの観点からのこのコードの重要性。
, , . , (assertions).
, -. , -, — .
, . - -.
- — . , .
. : . — .
. : , , . , , . , .
? . - . , .
:
, . . .
. -, . , .
?
, , . , . : . — , , .
— , . , , . — , .
- ( ) . , . - : , .
, . ( ), , ( ).
, , , : ( ).
, , . : . . — II .
, : , . . .
: , . :
( , );
( , ).
. 3, . — (), . — (), .
:
-. , . . , , , .
. :
. . , .
. , , .
. «» : , .
, . , .
? , . , — , — . : .
, . , . , , .
— (end-to-end) . . , , .
, . , , , . - , .
: . , , . .
— . , .
, . , , . - , .
- , , . : , .
— — , (end-to-end) . - , . . , .
. ; . , . , , . .
, ; . .
? : , . . , . , .
- CAP. , : (consistency) , (availability), (partition tolerance).
:
1. CAP ;
2. . — , , - Amazon — . .
: -, , .
. . , . , . . , .
. : ; - — ; - .
, – . : . , .
. - , -, — . ; , , (, ). CRUD- - .
— API, (, ). . , . , — .
« » « »
« » . . , , , .
« » . . , .
, : , . « ». — , -, — « » , -. -, .
-
-
統合テストとは何ですか？