単体テスト
余談ですが原則中の「もっとも効果的なテストレベル」として、ユニットテストを選び、テストピラミッドのテストレベル設計を行う事例をよく見ます。ただ現代的な開発では、ユニットテスト以外も有力な候補になっています。マイクロサービスアーキテクチャのようなサービスの群体ならAPIテストが有力です。FlutterといったモダンなFEフレームワークを作っているなら、フレームワークが提供する結合テストが有力です。 またユニットテストは、メリットを多く持つものの、次のようなデメリットも持ちます。
プロダクトの価値から離れる。魅力的なユーザビリティや、競争力のある高度な機能といった、プロダクト価値は、ユニットレベルのような細分化された世界では意識しにくくなります。プロダクト価値を意識せず、コードカバレッジを満たせばよい、のようなやり方を取ってしまう場合もあり得ます。
プロダクトコードに強結合する。コードの細部にテストが依存するため、変更・保守を行う手間が発生します。例えば機能の影響のないリファクタリングでもテストが壊れるといった状況対応です。
このようなデメリットを加味して、注力するテストレベルを選択すべきといえます。テストピラミッドでなく、APIテスト等結合テストを主体としたテストトロフィーを志向したほうが良い開発も少なくありません。 1単位の振る舞いを検証すること
実行時間が短いこと
他のテストケースから隔離された状態で実行されること