지금까지는 코드를 고칠 때마다 앱을 직접 실행해서 눌러보며 확인했다. 화면이 열 개를 넘고 기능이 늘면 이 방식은 한계가 온다. 한 곳을 고치고 다른 곳이 깨졌는지 매번 다 눌러볼 수는 없기 때문이다. 테스트는 이 확인 작업을 코드로 적어두고 명령 하나로 다시 돌리는 것이다.

Flutter에는 세 종류의 테스트가 있다. 범위가 좁고 빠른 순서로 이렇다.

• 단위 테스트(unit): 함수나 클래스 하나가 맞게 동작하는지 본다. 화면 없이 Dart 코드만 돌려서 매우 빠르다
• 위젯 테스트(widget): 위젯 하나를 가상의 화면에 올려서 보이는 것과 누르기 동작을 확인한다. 기기 없이 flutter test로 돈다
• 통합 테스트(integration): 진짜 앱을 기기나 에뮬레이터에서 돌려서 사용자처럼 처음부터 끝까지 눌러본다. 가장 느리다

빠르고 많이 → 느리고 적게가 기본 비율이다. 단위 테스트를 가장 많이, 통합 테스트는 핵심 흐름 몇 개만 쓴다.

1단계: 단위 테스트 - 가장 먼저, 가장 많이

간단한 클래스부터 해보자.

class Counter {
  int value = 0;
  void increment() => value++;
  void decrement() => value--;
}

테스트 파일은 프로젝트의 test/ 폴더에 두고, 파일 이름은 _test.dart로 끝낸다. test/counter_test.dart를 만든다.

import 'package:flutter_test/flutter_test.dart';

void main() {
  test('increment는 값을 1 올린다', () {
    final counter = Counter();

    counter.increment();

    expect(counter.value, 1);
  });

  test('decrement는 값을 1 내린다', () {
    final counter = Counter();

    counter.decrement();

    expect(counter.value, -1);
  });
}

flutter test

• test('설명', () { ... }): 테스트 하나다. 설명은 실패했을 때 어느 테스트인지 알려주는 이름이다
• expect(실제값, 기대값): 실제값이 기대한 것과 같은지 확인한다. 다르면 그 테스트가 실패한다
• 준비(Arrange), 실행(Act), 확인(Assert) 세 단계로 쓰면 읽기 쉽다. 위 코드의 빈 줄이 그 구분이다

테스트가 여러 개면 group으로 묶고, 매번 반복하는 준비는 setUp에 둔다.

void main() {
  group('Counter', () {
    late Counter counter;

    setUp(() {
      counter = Counter(); // 테스트마다 새로 만들어짐
    });

    test('처음 값은 0이다', () => expect(counter.value, 0));
    test('increment는 1 올린다', () {
      counter.increment();
      expect(counter.value, 1);
    });
  });
}

late와 setUp의 조합은 첫 글의 late final + initState와 같은 모양이다. setUp이 각 테스트보다 먼저 실행된다는 순서를 믿고 쓰는 것이다.

2단계: 가짜로 바꿔 끼우는 테스트 - mocktail

실제 앱에서 시험하고 싶은 건 UserRepository 같은 클래스다. 이건 서버에서 데이터를 받아오는 UserApiService에 의존한다. 서버에 진짜로 요청하면 테스트가 느리고, 인터넷이 없으면 실패한다. Repository 글과 의존성 주입 글에서 가짜를 끼우는 구조를 만들어 둔 이유가 여기서 나온다. 가짜를 쉽게 만들어주는 mocktail을 설치한다.

flutter pub add dev:mocktail

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

class MockUserApiService extends Mock implements UserApiService {}

void main() {
  late MockUserApiService service;
  late UserRepositoryImpl repo;

  setUp(() {
    service = MockUserApiService();
    repo = UserRepositoryImpl(service); // 생성자로 가짜를 넣는다
  });

  test('getUsers는 JSON을 User 목록으로 바꾼다', () async {
    when(() => service.fetchUsers()).thenAnswer(
      (_) async => [
        {'id': 1, 'name': '홍길동'},
      ],
    );

    final users = await repo.getUsers();

    expect(users.single.name, '홍길동');
    verify(() => service.fetchUsers()).called(1);
  });

  test('서버가 실패하면 에러가 그대로 올라온다', () {
    when(() => service.fetchUsers()).thenThrow(Exception('서버 오류'));

    expect(() => repo.getUsers(), throwsA(isA<Exception>()));
  });
}

• class MockUserApiService extends Mock implements UserApiService {}: 상속 글의 implements로, UserApiService와 같은 모양의 가짜를 만든다. Mock이 호출을 기록하고 정해둔 답을 돌려준다
• when(() => service.fetchUsers()).thenAnswer(...): "이 함수가 불리면 이렇게 답해라"를 정한다. Future를 돌려주는 함수는 thenAnswer를 쓴다
• thenThrow(...): 일부러 실패하게 만든다. 서버가 실패했을 때를 서버 없이 시험할 수 있다
• verify(...).called(1): 그 함수가 정확히 한 번 불렸는지 확인한다
• throwsA(isA<Exception>()): 에러가 던져지는지 확인한다

서버 없이 에러 상황까지 시험할 수 있다는 게 가장 큰 효과다. 에러 처리 글에서 만든 try/catch와 에러 화면이 제대로 동작하는지도 이렇게 확인한다.

삽질 포인트: mocktail에서 자주 막히는 곳

• 정해두지 않은 함수를 부르면 에러가 난다. when으로 답을 정하지 않은 함수를 코드가 부르면 null이 돌아와서 타입 에러가 난다. 시험하는 코드가 호출하는 함수는 모두 when으로 정해둔다
• any()를 내가 만든 클래스에 쓰면 막힌다. when(() => repo.save(any()))처럼 User를 any()로 받으려면, 먼저 registerFallbackValue(User(...))로 예시 값을 하나 등록해야 한다. int, String 같은 기본 타입은 필요 없다
• Mock은 implements로 만들었으니 추상 클래스를 바로 가짜로 만들 수 있다. Repository를 abstract class로 정의해 두었다면 MockUserRepository를 그냥 만들면 된다

3단계: 위젯 테스트 - 화면이 보이고 눌러지는지

버튼을 누르면 숫자가 올라가는 위젯이 있다고 하자.

class CounterPage extends StatefulWidget {
  const CounterPage({super.key});
  @override
  State<CounterPage> createState() => _CounterPageState();
}

class _CounterPageState extends State<CounterPage> {
  int count = 0;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Column(
        children: [
          Text('$count'),
          ElevatedButton(
            key: const Key('increment'),
            onPressed: () => setState(() => count++),
            child: const Text('+1'),
          ),
        ],
      ),
    );
  }
}

import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';

void main() {
  testWidgets('버튼을 누르면 숫자가 1 올라간다', (tester) async {
    await tester.pumpWidget(const MaterialApp(home: CounterPage()));

    expect(find.text('0'), findsOneWidget);

    await tester.tap(find.byKey(const Key('increment')));
    await tester.pump();

    expect(find.text('1'), findsOneWidget);
  });
}

• testWidgets: 위젯 테스트다. tester가 가상의 화면을 조종하는 도구다
• tester.pumpWidget(...): 위젯을 가상 화면에 올린다
• find.text('0'), find.byKey(...), find.byType(...): 화면에서 위젯을 찾는 파인더다
• findsOneWidget, findsNothing: 찾은 개수가 하나인지, 하나도 없는지 확인한다
• tester.tap(...): 누른다. 글자를 입력하려면 tester.enterText(...)를 쓴다
• tester.pump(): 화면을 한 프레임 다시 그린다. setState 후에 이걸 불러야 바뀐 화면이 반영된다

파인더는 find.text보다 find.byKey나 find.byType이 오래간다. 글자는 언어를 바꾸거나 문구를 고치면 테스트가 깨지지만, 키는 그대로이기 때문이다.

삽질 포인트: 위젯 테스트에서 자주 막히는 곳

• MaterialApp으로 감싸지 않으면 에러가 난다. 위젯 글에서 Text는 위에서 내려오는 방향과 테마가 필요하다고 했다. 테스트에서도 마찬가지라서 Directionality나 Material이 없다는 에러가 난다. MaterialApp(home: ...)으로 감싸서 올린다
• pump와 pumpAndSettle을 구분한다. pump()는 한 프레임만 그린다. pumpAndSettle()은 애니메이션이 끝날 때까지 반복해서 그린다. 그런데 끝나지 않는 애니메이션(계속 도는 CircularProgressIndicator 등)이 화면에 있으면 pumpAndSettle이 끝나지 않아 시간 초과 에러가 난다. 그럴 때는 pump(const Duration(milliseconds: 100))로 직접 시간을 진행시킨다
• 찾는 글자가 화면에 없다. tap이나 expect 전에 pump를 안 부르면 아직 그려지지 않은 상태다

상태 관리와 함께 시험하기

Riverpod으로 만든 화면은 ProviderScope의 overrides로 가짜 Repository를 끼워서 시험한다. 의존성 주입 글에서 본 그 구조다.

testWidgets('사용자 목록이 화면에 보인다', (tester) async {
  await tester.pumpWidget(
    ProviderScope(
      overrides: [
        userRepositoryProvider.overrideWithValue(FakeUserRepository()),
      ],
      child: const MaterialApp(home: UserListView()),
    ),
  );

  await tester.pumpAndSettle(); // 데이터가 도착할 때까지

  expect(find.text('홍길동'), findsOneWidget);
});

서버 없이 "로딩이 끝나면 이름이 보인다"를 시험한다. 에러 상태는 thenThrow를 쓰는 가짜로 바꿔서 "에러 문구와 다시 시도 버튼이 보인다"를 같은 방식으로 확인한다. Bloc은 bloc_test 패키지가 Cubit의 상태 변화를 순서대로 확인하는 도구를 준다.

4단계: 통합 테스트 - 진짜 앱을 처음부터 끝까지

단위, 위젯 테스트는 일부분만 본다. 로그인 후 목록을 불러와서 상세 화면까지 가는 전체 흐름이 이어지는지는 통합 테스트로 본다. 설치부터 한다.

flutter pub add 'dev:integration_test:{"sdk":"flutter"}'

integration_test/ 폴더를 만들고 app_test.dart를 쓴다.

import 'package:flutter_test/flutter_test.dart';
import 'package:integration_test/integration_test.dart';
import 'package:my_app/main.dart' as app;

void main() {
  IntegrationTestWidgetsFlutterBinding.ensureInitialized();

  testWidgets('로그인 후 환영 문구가 보인다', (tester) async {
    app.main();
    await tester.pumpAndSettle();

    await tester.enterText(find.byKey(const Key('email')), 'test@mail.com');
    await tester.enterText(find.byKey(const Key('password')), '123456');
    await tester.tap(find.byKey(const Key('login')));
    await tester.pumpAndSettle();

    expect(find.text('환영합니다'), findsOneWidget);
  });
}

flutter test integration_test/app_test.dart

위젯 테스트와 쓰는 도구(tester, find, expect)가 같다. 달라지는 건 진짜 앱이 기기나 에뮬레이터에서 실행된다는 점이다. 그래서 느리고, 서버나 로그인 같은 환경이 준비되어 있어야 한다. 결제나 로그인처럼 깨지면 안 되는 핵심 흐름 몇 개만 통합 테스트로 두고, 나머지는 단위와 위젯 테스트로 채운다.

무엇을 시험하나

Flutter 공식 아키텍처 가이드는 Service, Repository, ViewModel 클래스마다 단위 테스트를 쓰라고 권한다. 화면을 계층으로 나눠둔 덕분에 가능한 일이다. 시작할 때는 이 순서가 부담이 적다.

• 1순위: 계산, 변환, 검증 같은 순수한 로직 (단위 테스트)
• 2순위: Repository와 ViewModel (가짜를 끼운 단위 테스트)
• 3순위: 에러 화면, 빈 목록 같은 화면 상태 (위젯 테스트)
• 4순위: 로그인에서 결제까지 같은 핵심 흐름 (통합 테스트)

Android, iOS와 비교하면

// Kotlin - JUnit + MockK, Compose 테스트
@Test fun increment() { val c = Counter(); c.increment(); assertEquals(1, c.value) }

@get:Rule val rule = createComposeRule()
@Test fun click() {
    rule.setContent { CounterScreen() }
    rule.onNodeWithTag("increment").performClick()
    rule.onNodeWithText("1").assertExists()
}

// Swift - XCTest
func testIncrement() {
    let counter = Counter()
    counter.increment()
    XCTAssertEqual(counter.value, 1)
}

• 단위 테스트: Flutter test + expect / Android JUnit + assertEquals / iOS XCTest + XCTAssertEqual
• 가짜 만들기: Flutter mocktail / Android MockK, Mockito / iOS protocol을 따르는 가짜 직접 작성
• 화면 테스트: Flutter testWidgets, find, tester.tap / Compose createComposeRule, onNodeWithText, performClick / iOS는 XCUITest나 ViewInspector
• 통합 테스트: Flutter integration_test / Android Espresso, Compose UI 테스트 / iOS XCUITest
• 명령: Flutter flutter test / Android ./gradlew test / iOS Xcode의 Test

Compose의 createComposeRule과 Flutter의 testWidgets가 거의 같은 역할이다. 둘 다 기기 없이 화면을 올려서 찾고 누르고 확인한다. Flutter는 flutter test 한 줄로 단위와 위젯 테스트를 같이 돌리고, 통합 테스트만 별도 명령이라는 점이 간단하다.

정리

• 테스트는 확인 작업을 코드로 적어두고 flutter test로 다시 돌리는 것이고, 단위(빠르고 많이), 위젯(화면 한 조각), 통합(진짜 앱, 느리고 적게) 세 종류가 있다
• 단위 테스트는 test/ 폴더의 _test.dart 파일에 test와 expect로 쓰고, 반복되는 준비는 setUp에 둔다
• 서버 같은 의존성은 mocktail의 Mock으로 가짜를 만들어 when(...).thenAnswer로 답을 정하고, thenThrow로 에러 상황도 시험한다
• 위젯 테스트는 testWidgets에서 pumpWidget으로 올리고, find로 찾고, tester.tap 뒤에 pump를 불러 확인한다. MaterialApp으로 감싸야 하고, 끝나지 않는 애니메이션이 있으면 pumpAndSettle이 시간 초과된다
• Riverpod 화면은 overrides로 가짜 Repository를 끼워서 서버 없이 시험하고, 통합 테스트는 핵심 흐름 몇 개만 integration_test로 쓴다
• 계층을 나눠둔 덕분에 Service, Repository, ViewModel마다 단위 테스트를 쓸 수 있다

다음 글에서는 앱을 여러 언어로 보여주는 다국어(l10n)와 앱 아이콘, 스플래시 화면 설정을 다뤄보겠다.