ユニットテストは、コード内で1つのユニットを実行します。それらは、単一のクラスやクラス内の単一のメソッドなど、個別の何かをテストします。大規模なアプリケーションやライブラリには、単体テストで効果的にテストできるよりも多くのパーツが含まれます。アプリケーションのさまざまな部分が正しく連携していることを確認するテストは、統合テストと呼ばれます。
統合テストは重要です
統合テストと単体テストはどちらも、コードに役立つ機能を提供します。統合テストは、アプリケーションの約束された機能がユーザーにとって正しく機能していることを確認するのに役立つため、特に価値があります。単体テストはすべて（正しく）合格する可能性がありますが、アプリケーションピース間のインターフェイスが正しくメッシュされていない場合、アプリケーションが壊れたり、使用できなくなったりする可能性があります。
統合テストで機能の記述を開始することには、2つ目の利点があります。統合テストは、単体テストの記述を促進できます。統合テストの手順が失敗すると、機能を構築するために構築する必要のあるユニットを示す可能性があります。単体テストのコレクションは逆に機能して、統合テストの作成を促進することはできません。
統合テストの実装
UnitConverterは小さな部分に分割され、データベースを活用して変換情報を保存するようになりました。その結果、コンバーターは、UnitDatabase変換マッピングの保守と要求の作業を処理するに依存し ます。単体テストでUnitConverterは、データベースの代わりにテストダブルを使用し、テストを変換ロジックに集中させます。私たちは、間の連携を確認する統合テストを必要 UnitConverterとUnitDatabase。
統合テストでのモックを避ける
マルチクラスコードの単体テストでは、テストダブルを使用して他のクラスの代わりになり、共同作業者がテスト対象システム（SUT）の動作に導入する可能性のある論理順列の数を減らすのが一般的です。テストダブルは、ファイルシステムやデータベースなどの低速操作との相互作用を回避することにより、単体テストを高速化するのに役立ちます。統合テストでは、実際の共同作業者を使用するテストを作成し、それらを実行して、コンポーネント間のインターフェイス（コンポーネントをまとめる「接着剤」）が期待どおりに機能することを確認するのが最善の場合がよくあります。
これは、すべての共同作業者を使用してコード全体をテストするテストです。
describe "integrating the database with the converter" do
def create_and_populate_database(filename)
db = UnitDatabase.new(filename)
db.clear_conversions
db.add_conversion(canonical_unit: :liter, unit: :cup, ratio: 4.22675)
db.add_conversion(canonical_unit: :liter, unit: :liter, ratio: 1)
db.add_conversion(canonical_unit: :liter, unit: :pint, ratio: 2.11338)
db.add_conversion(canonical_unit: :gram, unit: :gram, ratio: 1)
db.add_conversion(canonical_unit: :gram, unit: :kilogram, ratio: 1000)
db
end
it "converts between cups and pints through liters" do
database_filename = "test_db.sqlite"
db = create_and_populate_database(database_filename)
cups = Quantity.new(amount: 2, unit: :cup)
converter = UnitConverter.new(cups, :pint, db)
result = converter.convert
expect(result.amount).to be_within(0.001).of(1)
expect(result.unit).to eq(:pint)
# teardown!
file.delete(database_filename)
endend
データの追加と副作用の回避
統合テストでは、多くの場合、データベースにデータを追加するか、他の永続的な状態を設定して、コンポーネントの相互作用の段階を設定する必要があります。テストが後のテスト（またはテストスイートの実行）を壊す可能性のある状態を残さないようにすることが重要です。
テストが確実にクリーンアップされるようにする1つの方法は、ensureステートメントを使用してテストの分解ステップを実行することです。
begin
result = converter.convert
expect(result.amount).to be_within(0.001).of(1)
expect(result.unit).to eq(:pint)
ensure
File.delete(database_filename)
end
これは繰り返しになる可能性があり、読者がテストの実行内容を理解しているときに、追加の認知的負荷がかかります。より良いアプローチは、ensure ステートメントをaroundブロックに入れることです。
around do |example|
begin
example.run
ensure
file.delete(database_filename)
endend
テストステップを明示的な実行から暗黙的な実行に移動することをお勧めするのは奇妙に思えるかもしれませんが（したがって、読者の視点からそれを隠す）、クリーンアップはテストスイートの実装の詳細であり、ユーザーが考慮することは重要ではありません。個々のテストを読むとき。
