Service Locator Pattern 테스트 전략 완벽 가이드

Service Locator Pattern을 사용하는 애플리케이션의 효과적인 테스트 전략을 배워봅니다. 목(Mock) 서비스 등록, 격리된 테스트 환경 구성, 그리고 실무에서 바로 쓸 수 있는 테스트 기법들을 다룹니다.

---

목차

1. 테스트용 Service Locator 초기화
2. Mock 서비스 등록
3. 단위 테스트 격리 전략
4. 통합 테스트에서 Service Locator 활용
5. setUp과 tearDown 패턴
6. 여러 Mock 시나리오 테스트
7. 비동기 서비스 테스트
8. Widget 테스트와 Service Locator

---

1. 테스트용 Service Locator 초기화

시작하며

여러분이 Flutter 앱의 단위 테스트를 작성할 때 이런 경험 있으신가요? 테스트를 실행하면 "Service not found" 에러가 발생하거나, 이전 테스트의 서비스가 남아서 다음 테스트에 영향을 주는 상황 말이죠.

이런 문제는 Service Locator가 전역 싱글톤으로 동작하기 때문에 발생합니다. 한 테스트에서 등록한 서비스가 다른 테스트에도 영향을 주고, 테스트 순서에 따라 결과가 달라질 수 있습니다.

이는 테스트의 신뢰성을 크게 떨어뜨리죠. 바로 이럴 때 필요한 것이 테스트 전용 Service Locator 초기화입니다.

각 테스트가 시작될 때마다 깨끗한 상태에서 시작할 수 있게 해주는 핵심 기법이죠.

개요

간단히 말해서, 테스트용 Service Locator 초기화는 각 테스트 케이스가 독립적인 환경에서 실행되도록 보장하는 것입니다. 실제 프로덕션 코드에서는 앱이 시작될 때 한 번만 서비스를 등록하지만, 테스트에서는 매번 새로 시작해야 합니다.

예를 들어, API 테스트를 할 때 이전 테스트에서 사용한 Mock 객체가 남아있으면 예상치 못한 동작이 발생할 수 있습니다. 기존에는 테스트가 끝나고 서비스를 수동으로 정리했다면, 이제는 get_it 패키지의 reset() 메서드를 사용해 자동으로 모든 서비스를 제거할 수 있습니다.

이 기법의 핵심 특징은 첫째, 테스트 격리(Test Isolation)를 보장하고, 둘째, 테스트 순서에 무관하게 일관된 결과를 제공하며, 셋째, 테스트 설정을 단순화한다는 점입니다. 이러한 특징들이 테스트의 신뢰성과 유지보수성을 크게 향상시킵니다.

코드 예제

import 'package:get_it/get_it.dart';
import 'package:flutter_test/flutter_test.dart';

final getIt = GetIt.instance;

void main() {
  // 각 테스트 전에 실행
  setUp(() {
    // Service Locator 완전히 초기화
    getIt.reset();

    // 테스트용 서비스 등록
    getIt.registerSingleton<ApiService>(MockApiService());
    getIt.registerLazySingleton<AuthService>(() => MockAuthService());
  });

  // 각 테스트 후에 실행
  tearDown(() {
    // 모든 서비스 제거하여 다음 테스트에 영향 없도록
    getIt.reset();
  });
}

설명

이것이 하는 일: 테스트가 실행되기 전에 Service Locator를 완전히 비우고 새로운 테스트용 서비스를 등록하여, 각 테스트가 깨끗한 상태에서 시작할 수 있게 합니다. 첫 번째로, setUp() 함수 내에서 getIt.reset()을 호출합니다.

이 메서드는 Service Locator에 등록된 모든 서비스를 제거하고, 모든 싱글톤 인스턴스를 파괴합니다. 왜 이렇게 하냐면, 이전 테스트에서 등록된 서비스가 현재 테스트에 영향을 주는 것을 방지하기 위해서입니다.

그 다음으로, reset() 후에 테스트에 필요한 Mock 서비스들을 등록합니다. registerSingleton은 이미 생성된 인스턴스를 등록하고, registerLazySingleton은 실제로 사용될 때까지 생성을 지연시킵니다.

내부적으로 Service Locator는 이 서비스들을 Map 구조로 관리하며, 타입을 키로 사용해 빠르게 찾을 수 있습니다. 마지막으로, tearDown() 함수에서 다시 reset()을 호출하여 테스트가 끝난 후 모든 것을 정리합니다.

이렇게 하면 다음 테스트가 실행될 때 아무런 잔여물이 남아있지 않게 됩니다. 여러분이 이 코드를 사용하면 테스트 간 독립성이 보장되어 테스트 순서와 관계없이 항상 동일한 결과를 얻을 수 있습니다.

또한 각 테스트가 예측 가능하고 디버깅이 쉬워지며, CI/CD 환경에서도 안정적으로 실행됩니다.

실전 팁

💡 reset() 대신 resetLazySingleton()을 사용하면 특정 서비스만 선택적으로 재설정할 수 있어, 일부 서비스는 유지하면서 특정 서비스만 교체할 때 유용합니다

💡 테스트에서 reset()을 빼먹으면 "Object/factory with type X is already registered" 에러가 발생하므로, 항상 setUp에 reset()을 첫 줄에 작성하세요

💡 프로덕션 코드와 테스트 코드에서 서로 다른 GetIt 인스턴스를 사용하고 싶다면 GetIt.asNewInstance()로 별도 인스턴스를 만들 수 있습니다

💡 setUp에서 등록한 서비스가 많다면, 별도의 TestServiceLocator 클래스를 만들어 setupForTest() 메서드로 캡슐화하면 테스트 코드가 훨씬 깔끔해집니다

💡 통합 테스트(integration test)에서는 reset()을 사용하지 말고 실제 서비스를 사용하여 전체 시스템이 제대로 동작하는지 검증하세요

---

2. Mock 서비스 등록

시작하며

여러분이 API를 호출하는 기능을 테스트할 때 이런 고민 해보셨나요? 실제 서버에 요청을 보내면 네트워크 상태에 따라 테스트가 실패할 수 있고, 테스트 데이터가 실제 DB에 저장되는 문제가 생깁니다.

이런 문제는 실제 개발 현장에서 테스트를 느리고 불안정하게 만듭니다. 외부 의존성이 있는 테스트는 CI/CD 파이프라인에서 무작위로 실패하고, 개발자들은 "내 컴퓨터에서는 되는데"라고 말하게 됩니다.

더 심각한 건 테스트 중에 실수로 프로덕션 데이터베이스에 접근할 위험도 있죠. 바로 이럴 때 필요한 것이 Mock 서비스입니다.

실제 서비스를 흉내 내는 가짜 객체를 만들어 외부 의존성 없이 빠르고 안정적인 테스트를 작성할 수 있습니다.

개요

간단히 말해서, Mock 서비스는 실제 서비스의 인터페이스를 구현하되 테스트에 필요한 가짜 데이터를 반환하는 객체입니다. 실무에서는 API 서비스, 데이터베이스, 파일 시스템 등 외부 리소스에 의존하는 코드를 자주 작성합니다.

예를 들어, 사용자 인증 기능을 테스트할 때 실제로 서버에 로그인 요청을 보낼 필요 없이, Mock 객체가 "로그인 성공" 또는 "비밀번호 오류" 같은 응답을 즉시 반환하게 할 수 있습니다. 기존에는 실제 서비스를 사용해 통합 테스트만 작성했다면, 이제는 Mock 서비스로 단위 테스트를 빠르게 작성하고, 통합 테스트는 핵심 플로우에만 집중할 수 있습니다.

이 기법의 핵심 특징은 첫째, 테스트가 외부 의존성 없이 독립적으로 실행되고, 둘째, 테스트 속도가 획기적으로 빨라지며(네트워크 I/O 제거), 셋째, 에러 상황을 쉽게 시뮬레이션할 수 있다는 점입니다. 이러한 특징들이 테스트 주도 개발(TDD)을 실천 가능하게 만듭니다.

코드 예제

import 'package:mockito/mockito.dart';
import 'package:mockito/annotations.dart';

// Mock 클래스 자동 생성 어노테이션
@GenerateMocks([ApiService, DatabaseService])
void main() {}

// 또는 수동으로 Mock 클래스 작성
class MockApiService extends Mock implements ApiService {
  @override
  Future<User> getUser(String id) async {
    // 테스트용 가짜 데이터 반환
    return User(id: id, name: 'Test User', email: 'test@example.com');
  }

  @override
  Future<void> updateUser(User user) async {
    // 실제로는 아무것도 하지 않음
    return;
  }
}

// Service Locator에 등록
setUp(() {
  getIt.reset();
  getIt.registerSingleton<ApiService>(MockApiService());
});

설명

이것이 하는 일: 실제 서비스의 인터페이스를 구현한 가짜 객체를 만들어 Service Locator에 등록하고, 테스트 코드가 이 Mock 객체를 사용하도록 합니다. 첫 번째로, @GenerateMocks 어노테이션을 사용하면 mockito 패키지가 빌드 시점에 자동으로 Mock 클래스를 생성합니다.

이 방식은 타입 안정성을 보장하고 코드 중복을 줄여줍니다. 왜 이렇게 하냐면, 수동으로 모든 메서드를 구현하는 것은 번거롭고 실제 인터페이스가 변경될 때 Mock도 함께 업데이트해야 하기 때문입니다.

그 다음으로, Mock 클래스를 직접 작성하는 방법도 있습니다. extends Mock implements ApiService 문법을 사용하면 mockito의 기능을 활용하면서 원하는 메서드만 오버라이드할 수 있습니다.

내부적으로 Mock 클래스는 메서드 호출을 기록하고, when() 같은 mockito 함수로 동작을 제어할 수 있게 해줍니다. 마지막으로, setUp() 함수에서 MockApiService 인스턴스를 생성해 Service Locator에 등록합니다.

이제 프로덕션 코드에서 getIt<ApiService>()를 호출하면 실제 API가 아닌 Mock 객체가 반환되어, 네트워크 없이도 테스트가 실행됩니다. 여러분이 이 코드를 사용하면 테스트 실행 시간이 수십 배 빨라지고, 네트워크 상태와 무관하게 안정적인 테스트를 작성할 수 있습니다.

또한 에러 응답이나 타임아웃 같은 특수 상황도 쉽게 재현할 수 있어 엣지 케이스 테스트가 가능해집니다.

실전 팁

💡 mockito의 when() 함수를 사용하면 특정 입력에 대해 원하는 값을 반환하도록 설정할 수 있습니다: when(mockApi.getUser('123')).thenAnswer((_) async => testUser)

💡 verify() 함수로 Mock 메서드가 실제로 호출되었는지, 몇 번 호출되었는지 검증할 수 있어 간접적인 출력(indirect output)을 테스트할 때 유용합니다

💡 Mock 객체를 여러 테스트에서 재사용할 때는 reset(mockObject)을 호출해 이전 테스트의 설정을 지워야 예상치 못한 동작을 방지할 수 있습니다

💡 복잡한 Mock 시나리오는 별도의 TestDouble 클래스로 분리하면 테스트 코드가 더 읽기 쉬워지고, 여러 테스트 파일에서 재사용할 수 있습니다

💡 실제 서비스와 Mock 서비스가 동일한 인터페이스를 구현하는지 확인하려면 추상 클래스나 인터페이스를 먼저 정의하고, 두 클래스 모두 이를 구현하도록 설계하세요

---

3. 단위 테스트 격리 전략

시작하며

여러분이 테스트 스위트를 실행했을 때 이런 경험 있으신가요? 개별 테스트는 모두 통과하는데, 전체를 실행하면 일부가 실패하는 상황 말이죠.

또는 테스트 실행 순서를 바꾸면 결과가 달라지는 이상한 현상도 있습니다. 이런 문제는 테스트 간 상태 공유 때문에 발생합니다.

Service Locator는 전역 싱글톤이기 때문에, 한 테스트에서 변경한 서비스 상태가 다른 테스트에 영향을 줍니다. 예를 들어, 첫 번째 테스트에서 사용자를 로그인 상태로 만들면, 두 번째 테스트가 로그아웃 상태를 가정하더라도 여전히 로그인되어 있을 수 있죠.

바로 이럴 때 필요한 것이 단위 테스트 격리 전략입니다. 각 테스트가 완전히 독립적으로 실행되어 다른 테스트의 영향을 받지 않도록 보장하는 체계적인 접근법입니다.

개요

간단히 말해서, 단위 테스트 격리는 각 테스트가 자신만의 독립적인 환경에서 실행되도록 보장하여, 테스트 순서나 다른 테스트의 상태에 영향을 받지 않게 하는 것입니다. 실무에서는 수십, 수백 개의 테스트가 동시에 실행되고, 여러 개발자가 동시에 테스트를 추가합니다.

예를 들어, 장바구니 기능 테스트와 결제 기능 테스트가 같은 UserService를 사용한다면, 한 테스트에서 사용자 정보를 변경했을 때 다른 테스트가 예상치 못한 데이터를 받을 수 있습니다. 기존에는 테스트 실행 순서를 신중하게 관리하거나, 테스트 끝에 수동으로 상태를 정리했다면, 이제는 setUp/tearDown 패턴과 Service Locator의 스코프 기능을 활용해 자동으로 격리할 수 있습니다.

이 전략의 핵심 특징은 첫째, 테스트가 어떤 순서로 실행되든 항상 같은 결과를 보장하고(멱등성), 둘째, 병렬 테스트 실행이 가능해지며, 셋째, 테스트 실패 원인을 빠르게 파악할 수 있다는 점입니다. 이러한 특징들이 대규모 프로젝트에서 테스트를 유지 가능하게 만듭니다.

코드 예제

void main() {
  // 그룹별로 테스트 격리
  group('UserService Tests', () {
    late MockApiService mockApi;
    late UserService userService;

    setUp(() {
      // 각 테스트마다 새로운 환경 구성
      getIt.reset();

      // 새로운 Mock 인스턴스 생성
      mockApi = MockApiService();
      getIt.registerSingleton<ApiService>(mockApi);

      // 테스트 대상 생성
      userService = UserService();
    });

    tearDown(() {
      // 테스트 후 완전히 정리
      getIt.reset();
    });

    test('로그인 성공 시 사용자 정보 저장', () {
      // 이 테스트는 완전히 독립적
    });
  });
}

설명

이것이 하는 일: group과 setUp/tearDown 패턴을 활용하여 각 테스트가 실행되기 전에 깨끗한 상태를 만들고, 테스트가 끝나면 모든 상태를 제거하여 완벽한 격리를 보장합니다. 첫 번째로, group() 함수로 관련된 테스트들을 묶습니다.

각 그룹은 자신만의 setUp/tearDown을 가질 수 있어, 테스트를 논리적으로 조직화할 수 있습니다. 왜 이렇게 하냐면, UserService 테스트와 PaymentService 테스트는 서로 다른 Mock 객체가 필요하고, 그룹별로 설정을 분리하면 코드 중복을 줄일 수 있기 때문입니다.

그 다음으로, setUp() 함수에서 late 키워드로 선언한 변수들을 초기화합니다. late는 변수가 사용되기 전에 반드시 초기화된다는 것을 컴파일러에 보장합니다.

내부적으로 각 test() 함수가 실행되기 직전에 setUp()이 호출되어 완전히 새로운 Mock 인스턴스와 서비스 객체가 생성됩니다. 이전 테스트에서 사용한 객체는 가비지 컬렉션되어 메모리에서 제거됩니다.

마지막으로, tearDown()에서 getIt.reset()을 호출하여 Service Locator를 비웁니다. 이렇게 하면 다음 테스트의 setUp()이 실행될 때 "이미 등록된 서비스" 에러가 발생하지 않고, 각 테스트가 진정으로 독립적으로 실행됩니다.

여러분이 이 코드를 사용하면 테스트를 무작위 순서로 실행하거나(--test-randomize-ordering-seed) 병렬로 실행해도(--concurrency) 모든 테스트가 안정적으로 통과합니다. 또한 테스트가 실패했을 때 다른 테스트의 영향이 아닌, 해당 테스트 자체의 문제임을 확신할 수 있어 디버깅 시간이 크게 줄어듭니다.

실전 팁

💡 setUpAll()과 tearDownAll()은 그룹 전체에서 한 번만 실행되므로, 무거운 초기화 작업(파일 로딩 등)은 여기서 하고 가벼운 상태 초기화는 setUp()에서 하세요

💡 테스트 격리가 제대로 되는지 확인하려면 flutter test --test-randomize-ordering-seed=random 명령으로 무작위 순서 실행을 시도해보세요

💡 여러 그룹이 공통 설정을 공유한다면, mixin이나 헬퍼 함수로 setUp 로직을 재사용하면 DRY(Don't Repeat Yourself) 원칙을 지킬 수 있습니다

💡 테스트 데이터를 fixture 파일로 분리하면 테스트 코드가 간결해지고, 다양한 시나리오를 쉽게 추가할 수 있습니다

💡 Integration Test에서는 격리보다는 상태 전이를 테스트하는 것이 목적이므로, 단위 테스트와 달리 setUp/tearDown을 최소화하고 연속된 시나리오를 작성하세요

---

4. 통합 테스트에서 Service Locator 활용

시작하며

여러분이 단위 테스트를 완벽하게 작성했는데도, 실제 앱을 실행하면 예상치 못한 버그가 발생하는 경험 있으신가요? 각 컴포넌트는 잘 동작하는데, 함께 동작할 때 문제가 생기는 거죠.

이런 문제는 컴포넌트 간 통합 지점에서 발생합니다. 단위 테스트는 각 부분이 올바르게 동작하는지 확인하지만, 실제 서비스들이 함께 동작할 때의 상호작용은 검증하지 못합니다.

예를 들어, AuthService와 ApiService가 각각 잘 동작하지만, 인증 토큰이 만료되었을 때 API 호출이 어떻게 처리되는지는 단위 테스트로 확인하기 어렵죠. 바로 이럴 때 필요한 것이 통합 테스트입니다.

Service Locator를 활용해 실제 서비스들이 함께 동작하는 환경을 구성하고, 전체 시스템이 제대로 통합되었는지 검증할 수 있습니다.

개요

간단히 말해서, 통합 테스트는 여러 컴포넌트가 함께 동작하는 것을 검증하는 테스트로, Service Locator를 통해 실제 서비스 인스턴스들을 주입하고 그들 간의 상호작용을 확인합니다. 실무에서는 API 호출 후 데이터베이스 저장, 인증 후 화면 전환, 결제 후 이메일 발송 같은 복잡한 플로우를 자주 구현합니다.

예를 들어, 사용자가 상품을 구매할 때 PaymentService, OrderService, NotificationService가 순차적으로 실행되는데, 이 전체 흐름이 제대로 동작하는지 확인하려면 통합 테스트가 필요합니다. 기존에는 Mock 서비스로만 테스트했다면, 이제는 실제 서비스와 일부 Mock을 조합하여 더 현실적인 테스트 환경을 만들 수 있습니다.

예를 들어 실제 데이터베이스는 SQLite in-memory로 사용하되, 외부 API는 Mock으로 대체하는 식이죠. 이 접근법의 핵심 특징은 첫째, 실제 프로덕션 환경에 가까운 테스트가 가능하고, 둘째, 컴포넌트 간 계약(interface contract)이 지켜지는지 검증하며, 셋째, 단위 테스트에서 놓칠 수 있는 통합 버그를 찾아낸다는 점입니다.

이러한 특징들이 배포 전 신뢰도를 크게 높여줍니다.

코드 예제

void main() {
  group('Integration Tests - User Registration Flow', () {
    setUp(() {
      getIt.reset();

      // 실제 서비스와 Mock 혼합
      getIt.registerSingleton<ApiService>(
        RealApiService(baseUrl: 'https://test-api.example.com')
      );

      // 테스트용 in-memory 데이터베이스
      getIt.registerSingleton<DatabaseService>(
        DatabaseService.inMemory()
      );

      // 외부 서비스는 Mock 사용
      getIt.registerSingleton<EmailService>(MockEmailService());
    });

    test('전체 회원가입 플로우 검증', () async {
      // 여러 서비스가 함께 동작하는 시나리오 테스트
      final authService = getIt<AuthService>();
      final result = await authService.register('user@test.com', 'pass123');

      expect(result.isSuccess, true);
      // DB에 실제로 저장되었는지 확인
      final dbUser = await getIt<DatabaseService>().findUser(result.userId);
      expect(dbUser, isNotNull);
    });
  });
}

설명

이것이 하는 일: 실제 프로덕션 환경과 유사한 테스트 환경을 구성하되, 외부 의존성은 제어 가능한 형태로 대체하여, 전체 시스템의 통합 지점을 검증합니다. 첫 번째로, setUp()에서 실제 ApiService를 등록하되 테스트 서버 URL을 사용합니다.

이렇게 하면 실제 HTTP 통신이 발생하지만, 프로덕션 데이터에는 영향을 주지 않습니다. 왜 이렇게 하냐면, 네트워크 직렬화/역직렬화, 에러 처리 같은 실제 통신 로직을 검증하고 싶기 때문입니다.

그 다음으로, DatabaseService는 in-memory 모드로 등록합니다. SQLite의 :memory: 데이터베이스를 사용하면 실제 DB 엔진이 동작하지만 디스크에 저장되지 않아, 빠르고 격리된 테스트가 가능합니다.

내부적으로 각 테스트가 끝나면 메모리 DB가 자동으로 사라져서 다음 테스트에 영향을 주지 않습니다. 마지막으로, EmailService는 Mock으로 대체합니다.

실제로 이메일을 발송하면 테스트가 느려지고 외부 시스템에 의존하게 되므로, 이메일 발송 호출만 검증하고 실제 발송은 하지 않습니다. 테스트 코드에서는 verify()로 이메일 발송 메서드가 올바른 인자로 호출되었는지 확인할 수 있습니다.

여러분이 이 코드를 사용하면 단위 테스트로는 발견하기 어려운 통합 버그를 찾을 수 있습니다. 예를 들어, API 응답의 JSON 구조가 변경되었을 때, 데이터베이스 트랜잭션이 올바르게 커밋되는지, 여러 서비스 간 데이터 흐름이 정확한지 등을 검증할 수 있습니다.

이를 통해 배포 전 신뢰도를 크게 높일 수 있습니다.

실전 팁

💡 통합 테스트는 단위 테스트보다 느리므로, 핵심 비즈니스 플로우에만 작성하고 세부 로직은 단위 테스트로 커버하세요 (테스트 피라미드 원칙)

💡 테스트 환경을 위한 별도의 setupIntegrationTest() 함수를 만들어 프로덕션 설정과 분리하면, 실수로 프로덕션 서비스를 사용하는 것을 방지할 수 있습니다

💡 Flutter의 integration_test 패키지를 사용하면 실제 디바이스나 에뮬레이터에서 UI와 로직을 함께 테스트할 수 있어, 더 현실적인 환경에서 검증 가능합니다

💡 통합 테스트가 실패하면 여러 컴포넌트 중 어디가 문제인지 파악하기 어려우므로, 로깅을 추가하거나 단위 테스트를 먼저 확인하여 범위를 좁히세요

💡 CI/CD 파이프라인에서 통합 테스트는 별도 단계로 분리하여 병렬 실행하면 전체 빌드 시간을 줄일 수 있습니다

---

5. setUp과 tearDown 패턴

시작하며

여러분이 테스트 파일을 열었을 때 이런 광경을 본 적 있나요? 모든 테스트 케이스가 똑같은 초기화 코드로 시작하고, 같은 정리 코드로 끝나는 모습 말이죠.

10개의 테스트가 있으면 같은 코드가 20번 반복됩니다. 이런 코드 중복은 유지보수의 악몽입니다.

초기화 로직을 변경하려면 모든 테스트를 일일이 수정해야 하고, 하나라도 빼먹으면 테스트가 실패합니다. 더 심각한 건 중복 코드 사이에 미묘한 차이가 있을 때인데, 이는 찾기도 어렵고 예상치 못한 테스트 결과를 만들어냅니다.

바로 이럴 때 필요한 것이 setUp과 tearDown 패턴입니다. 반복되는 초기화와 정리 코드를 한 곳에 모아서 테스트 코드를 DRY(Don't Repeat Yourself)하게 만들고, 일관성을 보장할 수 있습니다.

개요

간단히 말해서, setUp과 tearDown은 각 테스트 케이스 실행 전후에 자동으로 호출되는 특별한 함수로, 테스트 환경 준비와 정리를 중앙화합니다. 실무에서는 수많은 테스트가 같은 초기 설정을 필요로 합니다.

예를 들어, UserService를 테스트하는 20개 테스트 케이스가 모두 Mock ApiService와 DatabaseService를 필요로 한다면, 이 설정을 한 곳에서 관리하는 것이 훨씬 효율적입니다. 기존에는 각 테스트에서 초기화 코드를 복사-붙여넣기 했다면, 이제는 setUp() 한 번으로 모든 테스트가 동일한 환경에서 시작할 수 있습니다.

테스트 로직도 초기화 코드 없이 본질적인 검증에만 집중할 수 있어 가독성이 크게 향상됩니다. 이 패턴의 핵심 특징은 첫째, 테스트 코드의 중복을 제거하고, 둘째, 모든 테스트가 일관된 환경에서 시작함을 보장하며, 셋째, 테스트 코드가 더 짧고 읽기 쉬워진다는 점입니다.

이러한 특징들이 대규모 테스트 스위트를 관리 가능하게 만듭니다.

코드 예제

void main() {
  // 그룹 레벨 변수 - 모든 테스트가 접근 가능
  late MockApiService mockApi;
  late MockDatabaseService mockDb;
  late UserService userService;

  // 각 테스트 전에 실행
  setUp(() {
    getIt.reset();

    // 공통 초기화 코드
    mockApi = MockApiService();
    mockDb = MockDatabaseService();

    getIt.registerSingleton<ApiService>(mockApi);
    getIt.registerSingleton<DatabaseService>(mockDb);

    userService = UserService();
  });

  // 각 테스트 후에 실행
  tearDown(() {
    getIt.reset();
    // 필요시 추가 정리 작업
  });

  test('사용자 생성 테스트', () {
    // 초기화 코드 없이 바로 테스트 로직 시작
    final user = userService.createUser('test@email.com');
    expect(user, isNotNull);
  });

  test('사용자 삭제 테스트', () {
    // 동일한 초기 환경에서 시작
    userService.deleteUser('user-id');
    verify(mockDb.delete('user-id')).called(1);
  });
}

설명

이것이 하는 일: 테스트 프레임워크가 각 test() 함수를 실행하기 전에 setUp()을 자동으로 호출하여 테스트 환경을 준비하고, 테스트가 끝나면 tearDown()을 호출하여 정리합니다. 첫 번째로, 그룹 레벨에서 late 키워드로 변수를 선언합니다.

late는 변수가 사용되기 전에 초기화될 것임을 보장하며, setUp()에서 실제 인스턴스가 할당됩니다. 왜 이렇게 하냐면, 모든 테스트 함수가 이 변수들에 접근해야 하지만, 각 테스트마다 새로운 인스턴스가 필요하기 때문입니다.

일반 변수로 선언하면 모든 테스트가 같은 인스턴스를 공유하게 되어 테스트 격리가 깨집니다. 그 다음으로, setUp() 함수에서 모든 초기화 로직을 수행합니다.

테스트 프레임워크는 내부적으로 각 test() 함수를 실행하기 직전에 setUp()을 호출합니다. 이 과정은 test1 → setUp → test1 실행 → tearDown → test2 → setUp → test2 실행 → tearDown 순서로 진행됩니다.

덕분에 각 테스트는 항상 동일한 초기 상태에서 시작합니다. 마지막으로, tearDown() 함수에서 정리 작업을 수행합니다.

Service Locator를 리셋하는 것 외에도, 열린 파일 핸들을 닫거나, 타이머를 취소하거나, 임시 파일을 삭제하는 등의 작업을 여기서 할 수 있습니다. 이렇게 하면 테스트가 시스템에 부작용(side effect)을 남기지 않습니다.

여러분이 이 코드를 사용하면 새로운 테스트를 추가할 때 초기화 코드를 작성할 필요가 없어 생산성이 크게 향상됩니다. 또한 초기화 로직을 변경할 때 setUp() 함수 하나만 수정하면 모든 테스트에 반영되어, 유지보수가 훨씬 쉬워집니다.

테스트 코드 자체도 더 짧고 명확해져서 새로운 팀원이 이해하기도 쉽습니다.

실전 팁

💡 setUpAll()과 tearDownAll()은 전체 그룹에서 한 번만 실행되므로, 비용이 큰 초기화(대용량 파일 로딩, DB 스키마 생성 등)는 여기서 하고 가벼운 초기화는 setUp()에서 하세요

💡 여러 그룹이 비슷한 setUp 로직을 공유한다면, 헬퍼 함수나 mixin으로 추출하여 재사용하세요: void commonSetUp() { ... } 형태로 만들어 각 setUp()에서 호출

💡 tearDown()은 테스트가 성공하든 실패하든 항상 실행되므로, 리소스 정리를 보장할 수 있어 메모리 누수나 파일 핸들 고갈을 방지합니다

💡 setUp()에서 비동기 작업이 필요하면 setUp(() async { await someAsyncInit(); })처럼 async 키워드를 사용할 수 있습니다

💡 테스트가 실패했을 때 setUp()의 어느 단계에서 문제가 생겼는지 파악하기 어려우므로, 복잡한 초기화는 여러 단계로 나누고 각 단계에 print()나 로그를 추가하세요

---

6. 여러 Mock 시나리오 테스트

시작하며

여러분이 에러 처리 코드를 작성했을 때 이런 고민 해보셨나요? "정말로 네트워크 에러가 발생하면 이 코드가 작동할까?" 또는 "타임아웃이 발생하면 재시도 로직이 제대로 동작할까?" 실제로 이런 상황을 재현하기는 정말 어렵습니다.

이런 문제는 실무에서 버그를 놓치게 만듭니다. 행복한 경로(happy path)만 테스트하고, 예외 상황은 "실제로 테스트하기 어려워서"라는 이유로 건너뛰게 됩니다.

그러다 프로덕션에서 에러가 발생하면 제대로 처리되지 않아 사용자가 나쁜 경험을 하게 되죠. 바로 이럴 때 필요한 것이 여러 Mock 시나리오 테스트입니다.

Mock 객체의 동작을 자유롭게 제어하여 성공, 실패, 타임아웃, 부분 성공 등 다양한 시나리오를 쉽게 재현하고 테스트할 수 있습니다.

개요

간단히 말해서, 여러 Mock 시나리오 테스트는 Mock 객체의 응답을 테스트마다 다르게 설정하여, 다양한 상황에서 코드가 올바르게 동작하는지 검증하는 것입니다. 실무에서는 네트워크 장애, 서버 에러, 잘못된 입력, 권한 부족 등 수많은 예외 상황을 처리해야 합니다.

예를 들어, 사용자 로그인 기능을 테스트할 때 성공 케이스뿐 아니라 잘못된 비밀번호, 계정 잠김, 네트워크 타임아웃, 서버 점검 중 등 다양한 실패 시나리오를 검증해야 합니다. 기존에는 실제 에러를 발생시키려면 복잡한 설정이 필요했다면, 이제는 mockito의 when().thenThrow()나 thenAnswer()를 사용해 코드 몇 줄로 모든 시나리오를 재현할 수 있습니다.

이 접근법의 핵심 특징은 첫째, 재현하기 어려운 상황을 쉽게 테스트하고, 둘째, 엣지 케이스와 에러 처리를 철저히 검증하며, 셋째, 실제 외부 시스템 없이도 모든 분기를 커버할 수 있다는 점입니다. 이러한 특징들이 코드 커버리지를 크게 높이고 프로덕션 안정성을 보장합니다.

코드 예제

void main() {
  late MockApiService mockApi;

  setUp(() {
    getIt.reset();
    mockApi = MockApiService();
    getIt.registerSingleton<ApiService>(mockApi);
  });

  test('성공 시나리오 - 사용자 데이터 반환', () {
    // 성공 응답 설정
    when(mockApi.getUser('123'))
        .thenAnswer((_) async => User(id: '123', name: 'Test'));

    final result = await userService.fetchUser('123');
    expect(result.name, 'Test');
  });

  test('실패 시나리오 - 네트워크 에러', () {
    // 예외 발생 설정
    when(mockApi.getUser('123'))
        .thenThrow(NetworkException('Connection failed'));

    expect(() => userService.fetchUser('123'), throwsA(isA<NetworkException>()));
  });

  test('타임아웃 시나리오', () async {
    // 지연 후 타임아웃
    when(mockApi.getUser('123'))
        .thenAnswer((_) async {
          await Future.delayed(Duration(seconds: 10));
          return User(id: '123', name: 'Test');
        });

    expect(() => userService.fetchUser('123').timeout(Duration(seconds: 5)),
           throwsA(isA<TimeoutException>()));
  });
}

설명

이것이 하는 일: mockito 라이브러리의 when() 함수를 사용하여 Mock 메서드가 호출될 때 반환할 값이나 발생시킬 예외를 설정하고, 각 시나리오에서 코드가 올바르게 동작하는지 검증합니다. 첫 번째로, when() 함수로 특정 메서드 호출을 가로챕니다.

when(mockApi.getUser('123'))는 "getUser가 '123' 인자로 호출되면"이라는 조건을 정의합니다. 왜 이렇게 하냐면, 같은 Mock 객체라도 호출 인자에 따라 다른 응답을 반환하도록 설정할 수 있어, 더 정교한 테스트가 가능하기 때문입니다.

그 다음으로, thenAnswer()나 thenThrow()로 Mock의 동작을 정의합니다. thenAnswer()는 함수를 받아 동적으로 값을 생성할 수 있고, async 함수를 사용해 비동기 동작도 시뮬레이션할 수 있습니다.

내부적으로 mockito는 메서드 호출을 가로채서(intercept) 실제 구현을 실행하지 않고, 여기서 정의한 동작을 대신 실행합니다. thenThrow()는 예외 객체를 받아 메서드 호출 시 해당 예외를 던지게 합니다.

마지막으로, 타임아웃 시나리오에서는 Future.delayed()로 의도적으로 응답을 지연시키고, .timeout()으로 실제 타임아웃을 발생시킵니다. 이렇게 하면 실제로 느린 네트워크 환경을 재현하지 않고도, 타임아웃 처리 로직이 올바른지 검증할 수 있습니다.

여러분이 이 코드를 사용하면 프로덕션에서 발생할 수 있는 모든 예외 상황을 미리 테스트할 수 있습니다. 코드 커버리지가 크게 향상되고, 특히 에러 처리 분기가 실제로 동작하는지 확신을 가질 수 있습니다.

또한 QA나 사용자가 발견하기 전에 버그를 찾아낼 수 있어, 프로덕션 안정성이 크게 높아집니다.

실전 팁

💡 any, anyNamed 같은 matcher를 사용하면 특정 인자가 아닌 모든 호출에 대해 Mock 동작을 설정할 수 있습니다: when(mockApi.getUser(any)).thenReturn(...)

💡 여러 시나리오를 한 번에 테스트하고 싶다면 test()를 반복하는 대신, 데이터 주도 테스트(data-driven test) 패턴을 사용하세요: for (var scenario in scenarios) test(scenario.name, () { ... })

💡 복잡한 시나리오는 별도의 헬퍼 함수로 캡슐화하여 재사용성을 높이세요: void setupSuccessScenario() { when(...).thenAnswer(...); }

💡 Mock 호출이 예상과 다른 인자로 호출되면 조용히 null을 반환하는데, 이를 방지하려면 throwOnMissingStub를 사용하거나 verify()로 호출을 명시적으로 검증하세요

💡 실제 프로덕션에서 발생한 버그를 발견하면, 그 시나리오를 재현하는 테스트를 추가하여(회귀 테스트) 같은 버그가 재발하지 않도록 보장하세요

---

7. 비동기 서비스 테스트

시작하며

여러분이 async/await를 사용하는 코드를 테스트할 때 이런 문제 겪어보셨나요? 테스트가 비동기 작업이 완료되기 전에 끝나버려서 실제로는 실패해야 하는데 통과하거나, 타이밍 이슈로 가끔씩만 실패하는 flaky test가 되는 거죠.

이런 문제는 비동기 코드의 본질적인 특성 때문에 발생합니다. 일반적인 동기 코드는 위에서 아래로 순차적으로 실행되지만, 비동기 코드는 언제 완료될지 예측할 수 없습니다.

예를 들어, API 호출 후 결과를 검증하려 할 때, 호출이 완료되기 전에 expect()가 실행되면 테스트는 잘못된 결과를 검증하게 됩니다. 바로 이럴 때 필요한 것이 비동기 서비스 테스트 기법입니다.

Flutter의 테스트 프레임워크가 제공하는 async/await 지원을 활용하여 비동기 작업을 올바르게 테스트하고, Future 완료를 보장할 수 있습니다.

개요

간단히 말해서, 비동기 서비스 테스트는 async/await 키워드를 사용하여 비동기 작업이 완료될 때까지 기다린 후 결과를 검증하는 것입니다. 실무에서는 대부분의 서비스가 비동기로 동작합니다.

API 호출, 데이터베이스 쿼리, 파일 I/O, 복잡한 계산 등 모든 것이 Future나 Stream을 반환합니다. 예를 들어, 사용자 프로필을 불러와서 UI에 표시하는 기능을 테스트할 때, API 호출이 완료되고 상태가 업데이트되기까지 기다려야 정확한 검증이 가능합니다.

기존에는 Future.delayed()나 콜백을 사용해 수동으로 타이밍을 맞췄다면, 이제는 async/await 문법으로 자연스럽게 비동기 흐름을 작성하고, 테스트 프레임워크가 자동으로 완료를 기다려줍니다. 이 기법의 핵심 특징은 첫째, 비동기 코드를 동기 코드처럼 읽기 쉽게 작성할 수 있고, 둘째, 테스트 프레임워크가 Future 완료를 자동으로 기다려주며, 셋째, 타이밍 이슈로 인한 flaky test를 방지한다는 점입니다.

이러한 특징들이 비동기 코드의 테스트를 안정적이고 유지보수하기 쉽게 만듭니다.

코드 예제

void main() {
  late MockApiService mockApi;
  late UserService userService;

  setUp(() {
    getIt.reset();
    mockApi = MockApiService();
    getIt.registerSingleton<ApiService>(mockApi);
    userService = UserService();
  });

  test('비동기 사용자 조회 테스트', () async {
    // Mock 비동기 응답 설정
    when(mockApi.getUser('123')).thenAnswer(
      (_) async => User(id: '123', name: 'Test User')
    );

    // await로 Future 완료 대기
    final user = await userService.fetchUser('123');

    // 완료 후 검증
    expect(user.name, 'Test User');
    verify(mockApi.getUser('123')).called(1);
  });

  test('여러 비동기 작업 순차 실행', () async {
    when(mockApi.getUser(any)).thenAnswer(
      (_) async => User(id: '1', name: 'User')
    );

    // 순차적으로 여러 작업 실행
    final user1 = await userService.fetchUser('1');
    final user2 = await userService.fetchUser('2');

    expect(user1.id, '1');
    expect(user2.id, '1'); // Mock이 같은 값 반환
  });
}

설명

이것이 하는 일: test() 함수를 async로 선언하여 내부에서 await 키워드를 사용할 수 있게 하고, 비동기 작업이 완료될 때까지 테스트 프레임워크가 자동으로 기다리도록 합니다. 첫 번째로, test() 함수의 콜백을 () async { }로 선언합니다.

이렇게 하면 함수가 Future<void>를 반환하게 되고, 테스트 프레임워크는 이 Future가 완료될 때까지 테스트를 끝내지 않습니다. 왜 이렇게 하냐면, 일반 함수로 작성하면 비동기 작업이 백그라운드에서 실행되는 동안 테스트가 즉시 종료되어, 실제 검증이 실행되지 않기 때문입니다.

그 다음으로, await 키워드로 Future가 완료되기를 기다립니다. await userService.fetchUser('123')은 fetchUser가 User 객체를 반환할 때까지 실행을 멈춥니다.

내부적으로 Dart의 이벤트 루프가 Future가 완료될 때까지 다른 작업을 처리하고, 완료되면 다음 줄로 진행합니다. 이는 동기적으로 보이지만 실제로는 비차단(non-blocking) 방식으로 동작합니다.

마지막으로, 여러 비동기 작업을 순차적으로 실행할 때도 await를 연속으로 사용하면 됩니다. 각 await는 이전 작업이 완료될 때까지 기다리므로, 의존성이 있는 작업들을 명확한 순서로 실행할 수 있습니다.

병렬로 실행하고 싶다면 Future.wait([future1, future2])를 사용하면 됩니다. 여러분이 이 코드를 사용하면 비동기 코드를 동기 코드만큼 쉽게 테스트할 수 있습니다.

타이밍 이슈로 인한 flaky test가 사라지고, 테스트가 항상 일관되게 동작합니다. 또한 코드가 순차적으로 읽혀서 테스트의 의도를 파악하기 쉬워지고, 유지보수가 훨씬 간편해집니다.

실전 팁

💡 비동기 테스트에서 타임아웃을 설정하려면 test('...', () async { ... }, timeout: Timeout(Duration(seconds: 5)))로 지정하여 무한 대기를 방지하세요

💡 Stream을 테스트할 때는 expectLater(stream, emits(value))나 emitsInOrder([value1, value2])를 사용하여 여러 이벤트를 순서대로 검증할 수 있습니다

💡 await을 빼먹으면 테스트가 Future 완료를 기다리지 않고 종료되므로, IDE의 "unawaited_futures" 린트 규칙을 활성화하여 실수를 방지하세요

💡 여러 비동기 작업을 병렬로 실행하려면 final results = await Future.wait([future1, future2, future3])를 사용하면 시간을 절약할 수 있습니다

💡 Mock 메서드가 비동기라면 반드시 thenAnswer(( ) async => value)를 사용하세요. thenReturn(Future.value(value))도 작동하지만 thenAnswer가 더 명확하고 에러 처리도 쉽습니다

---

8. Widget 테스트와 Service Locator

시작하며

여러분이 Flutter 위젯을 테스트할 때 이런 상황 겪어보셨나요? 위젯이 내부에서 Service Locator로 서비스를 가져오는데, 테스트에서는 어떻게 Mock 서비스를 주입해야 할지 막막한 거죠.

단순히 위젯만 렌더링하면 "Service not found" 에러가 발생합니다. 이런 문제는 Widget 테스트의 특수한 환경 때문에 발생합니다.

단위 테스트와 달리 Widget 테스트는 실제 Flutter 프레임워크를 초기화하고, 위젯 트리를 빌드하고, UI를 렌더링합니다. 이 과정에서 위젯이 getIt<SomeService>()를 호출하면 Service Locator에 서비스가 등록되어 있어야 합니다.

바로 이럴 때 필요한 것이 Widget 테스트에서의 Service Locator 활용입니다. testWidgets() 함수의 setUp에서 Mock 서비스를 등록하고, 위젯이 이를 사용하도록 하여 UI와 비즈니스 로직을 함께 테스트할 수 있습니다.

개요

간단히 말해서, Widget 테스트에서 Service Locator를 활용한다는 것은 testWidgets()의 setUp에서 Mock 서비스를 등록하여, 위젯이 실제 서비스 대신 테스트용 Mock을 사용하게 하는 것입니다. 실무에서는 위젯이 직접 비즈니스 로직을 포함하지 않고, Service Locator를 통해 서비스를 주입받는 구조를 많이 사용합니다.

예를 들어, UserProfileWidget이 UserService를 사용해 프로필을 불러온다면, 위젯 테스트에서 Mock UserService를 주입하여 네트워크 없이도 UI를 검증할 수 있습니다. 기존에는 위젯에 서비스를 생성자로 직접 전달했다면, 이제는 Service Locator 패턴을 사용해 위젯 코드를 변경하지 않고도 테스트 환경에서 Mock을 주입할 수 있습니다.

이는 프로덕션 코드와 테스트 코드의 분리를 더 명확하게 만듭니다. 이 접근법의 핵심 특징은 첫째, UI와 비즈니스 로직을 통합하여 테스트하고, 둘째, 위젯 코드를 수정하지 않고 테스트 가능하며, 셋째, 사용자가 실제로 보는 UI를 검증할 수 있다는 점입니다.

이러한 특징들이 E2E에 가까운 신뢰도 높은 테스트를 가능하게 합니다.

코드 예제

void main() {
  late MockUserService mockUserService;

  setUp(() {
    getIt.reset();

    // Widget 테스트용 Mock 서비스 등록
    mockUserService = MockUserService();
    getIt.registerSingleton<UserService>(mockUserService);
  });

  tearDown(() {
    getIt.reset();
  });

  testWidgets('사용자 프로필 위젯 표시 테스트', (WidgetTester tester) async {
    // Mock 응답 설정
    when(mockUserService.getCurrentUser()).thenAnswer(
      (_) async => User(id: '1', name: 'Test User', email: 'test@example.com')
    );

    // 위젯 렌더링
    await tester.pumpWidget(
      MaterialApp(home: UserProfileWidget())
    );

    // 비동기 작업 완료 대기
    await tester.pump();

    // UI 검증
    expect(find.text('Test User'), findsOneWidget);
    expect(find.text('test@example.com'), findsOneWidget);

    // 서비스 호출 검증
    verify(mockUserService.getCurrentUser()).called(1);
  });
}

설명

이것이 하는 일: Widget 테스트 환경에서 Service Locator에 Mock 서비스를 등록하고, 위젯을 렌더링하여 UI 요소가 올바르게 표시되는지, 그리고 내부적으로 올바른 서비스 호출이 발생하는지 검증합니다. 첫 번째로, setUp()에서 getIt.reset()으로 Service Locator를 초기화하고 Mock 서비스를 등록합니다.

이는 단위 테스트와 동일하지만, Widget 테스트에서는 Flutter 프레임워크도 함께 초기화됩니다. 왜 이렇게 하냐면, 위젯이 빌드될 때 getIt<UserService>()를 호출하면 여기서 등록한 Mock 객체를 받게 되어, 실제 네트워크 없이도 테스트가 가능하기 때문입니다.

그 다음으로, testWidgets() 함수 내에서 when()으로 Mock의 응답을 설정하고, tester.pumpWidget()으로 위젯을 렌더링합니다. 내부적으로 pumpWidget()은 위젯 트리를 빌드하고 첫 번째 프레임을 렌더링합니다.

하지만 비동기 작업(FutureBuilder 등)은 완료되지 않은 상태이므로, 추가로 tester.pump()나 tester.pumpAndSettle()을 호출하여 비동기 작업이 완료되고 UI가 업데이트될 때까지 기다립니다. 마지막으로, find.text()나 find.byType() 같은 Finder를 사용해 UI 요소를 찾고, expect()로 검증합니다.

findsOneWidget은 정확히 하나의 위젯이 발견되었는지 확인하고, findsNothing은 위젯이 없는지 확인합니다. 또한 verify()로 Mock 서비스가 예상대로 호출되었는지도 검증하여, UI뿐 아니라 비즈니스 로직도 함께 테스트합니다.

여러분이 이 코드를 사용하면 사용자가 실제로 보고 상호작용하는 UI를 테스트할 수 있습니다. 단위 테스트로는 발견하기 어려운 UI 버그(텍스트가 잘리거나, 버튼이 보이지 않는 등)를 찾아낼 수 있고, 동시에 비즈니스 로직도 검증하여 전체적인 테스트 신뢰도가 크게 향상됩니다.

실전 팁

💡 tester.pumpAndSettle()은 모든 애니메이션과 비동기 작업이 완료될 때까지 반복적으로 pump()를 호출하므로, 복잡한 UI 테스트에서 유용합니다

💡 위젯이 ChangeNotifier나 Provider를 사용한다면, Service Locator와 함께 사용할 때 순환 의존성을 조심하세요. 서비스는 Service Locator에, 상태는 Provider에 분리하는 것이 좋습니다

💡 find.byKey(Key('widget-key'))를 사용하면 고유한 위젯을 더 정확하게 찾을 수 있어, 동일한 텍스트나 타입이 여러 개 있을 때 유용합니다

💡 Widget 테스트는 단위 테스트보다 느리므로, 핵심 사용자 플로우에만 작성하고 세부 로직은 단위 테스트로 커버하세요

💡 Golden 테스트(스크린샷 비교)와 결합하면 UI 회귀를 자동으로 감지할 수 있어, 리팩토링 후 UI가 변경되지 않았는지 확인할 수 있습니다

이 가이드가 Service Locator Pattern 테스트 전략을 이해하고 실무에 적용하는 데 도움이 되길 바랍니다!

---