Hola, Amigos! На связи Павел Гершевич, Mobile Team Lead агентства продуктовой разработки Amiga и соавтор Flutter. Много. Недавно мы перевели для вас серию статей про модульное тестирование, но одна важная тема осталась за бортом. Сегодня познакомимся с тестированием BLoC при помощи модульных тестов.

Тестируем создание BLoC

Допустим, мы пишем экран входа в приложение по email и паролю и используем библиотеку flutter_bloc для управления состоянием. Тогда у нас будут такие состояния:

@immutable
abstract class LoginState {}

class LoginInitialState extends LoginState {}

class LoginDataState extends LoginState {
  final String? email;
  final String? password;

  ...
}

class LoginLoadingState extends LoginState {
  final String? email;
  final String? password;

  ...
}

class LoginSuccessState extends LoginState {}

class LoginErrorState extends LoginState {
  final String? email;
  final String? password;
  final String? errorToShow;

  ...
}

И конструктор нашего BLoC будет выглядеть так:

class LoginBloc extends Bloc<LoginEvent, LoginState> {
  final LoginRepository _loginRepository;


  LoginBloc(this._loginRepository) : super(LoginInitialState()) {
    ...
  }
}

В процессе тестирования, будем дополнять его логикой и взаимодействиями с другими классами.

Давайте теперь напишем первый тест, который будет проверять, что при создании BLoC, он имеет состояние LoginInitialState. Но сначала нужно создать сам BLoC. Для этого подготовим Mock-объект репозитория при помощи библиотеки mocktail, он будет создаваться всего один раз. А вот сам BLoC мы будет создавать для каждого теста единожды.

LoginRepository repository;
LoginBloc bloc;


setUp(() {
  repository = MockLoginRepository();
  bloc = LoginBloc(repository);
});

Далее напишем тест. Для этого нам нужно получить состояние из только что созданного BLoC и проверить его тип при помощи Matcher isA.

test('LoginBloc should be initialized with LoginInitialState', () {
  // act
  final state = bloc.state;


  // assert
  expect(state, isA<LoginInitialState>());
});

Теперь мы можем приступить к тестированию логики внутри BLoC.

Простые модульные тесты

Для того, чтобы нам и дальше тестировать BLoC, необходимо создать события и написать под это логику. Сделаем события для ввода email и пароля.

@immutable
abstract class LoginEvent {}


class EditedEmail extends LoginEvent {
  final String email;
  EditedEmail(this.email);
}


class EditedPassword extends LoginEvent {
  final String password;
  EditedPassword(this.password);
}

Также у состояний нам понадобятся геттеры для email и password. Для этого воспользуемся расширениями.

extension LoginStateX on LoginState {
  String? get emailStr {
    if (this is LoginInitialState || this is LoginSuccessState) {
      return null;
    } else if (this is LoginDataState) {
      return (this as LoginDataState).email;
    } else if (this is LoginLoadingState) {
      return (this as LoginLoadingState).email;
    } else if (this is LoginErrorState) {
      return (this as LoginErrorState).email;
    }
    return null;
  }
}

Напишем обработку данных событий.

on<EditedEmail>((event, emit) {
  emit(LoginDataState(
    email: event.email, 
    password: state.passwordStr,
  ));
});


on<EditedPassword>((event, emit) {
  emit(LoginDataState(
    email: state.emailStr,
    password: event.password, 
  ));
});

Приступим к тестированию, но стандартная библиотека для этого уже не подойдет. Нам нужен пакет bloc_test от создателей flutter_bloc.

Когда мы его поставили, можно перейти к самим тестам.

blocTest(
  'emits [LoginDataState] after adding email',
  build: () => bloc,
  act: (_bloc) => _bloc.add(EditedEmail('example@sample.com')),
  expect: () => [
    isA<LoginDataState>(),
  ],
);

В этом тесте нужно передать в build наш BLoC, созданный ранее. Его также можно создавать и в самом параметре. На самом деле, это наш шаг Arrange из методологии написания тестов AAA. Далее идет место для действий - act, который соответствует одноименному шагу, и expect для проверки того, что придет в BLoC.

Давайте добавим тест для события - ввод пароля.

blocTest(
  'emits [LoginDataState] after adding password',
  build: () => bloc,
  act: (_bloc) => _bloc.add(EditedPassword('myPass123')),
  expect: () => [
    isA<LoginDataState>(),
  ],
);

Тесты для сложного события

Есть событие самого входа:

class LoginButtonPressed extends LoginEvent {}

И его обработка:

on<LoginButtonPressed>((event, emit) async {
  emit(LoginLoadingState(
    email: state.emailStr,
    password: state.passwordStr,
  ));
  if (state.emailStr?.isNotEmpty == false ||
    state.emailStr?.isNotEmpty == false) {
      emit(LoginErrorState(
        email: state.emailStr,
        password: state.passwordStr,
        errorToShow: 'Email or password is empty',
      ));
    return;
  }


  try {
    await _loginRepository.login(
      email: state.emailStr,
      password: state.passwordStr,
    );
    emit(LoginSuccessState());
  } catch (_) {
    emit(LoginErrorState(
      email: state.emailStr,
      password: state.passwordStr,
      errorToShow: 'Server error',
    ));
  }
});

Если мы внимательно посмотрим на код, то увидим, что нужно протестировать следующие кейсы:

• Когда email пустой, получаем LoginErrorState с ошибкой “Email or password is empty”

• Когда пароль пустой, получаем LoginErrorState с ошибкой “Email or password is empty”

• Когда email и пароль пустые, получаем LoginErrorState с ошибкой “Email or password is empty”

• Когда все прошло успешно, получаем LoginSuccessState

• Если произошла ошибка где-то в репозитории, получаем LoginErrorState с ошибкой “Server error”

Также стоит отметить, что в каждом из этих случаев будет добавляться событие LoginLoadingState.

Давайте напишем тест для первого случая, второй и третий будут аналогичны ему.

blocTest(
  'emits [LoginErrorState] if email is null',
  build: () => bloc,
  seed: () => LoginDataState(
    email: null,
    password: 'myPass123',
  ) as LoginState,
  act: (_bloc) => _bloc.add(LoginButtonPressed()),
  expect: () => [
    isA<LoginLoadingState>(),
    isA<LoginErrorState>(),
  ],
);

Тут мы использовали еще одно свойство blocTest - seed, которое нужно для подстановки изначального состояния в BLoC. Таким образом, не требуется дополнительно вызывать все методы, иначе тест выглядел бы так:

blocTest(
  'emits [LoginErrorState] if email is null',
  build: () => bloc,
  act: (_bloc) {
    _bloc.add(EditedPassword('myPass123'));
    _bloc.add(LoginButtonPressed());
  },
  expect: () => [
    isA<LoginDataState>(),
    isA<LoginLoadingState>(),
    isA<LoginErrorState>(),
  ],
);

И мы бы не были точно уверены, что все события обработаются как надо.

Далее проверим успешный вход.

blocTest('emits [LoginSuccessState]',
  build: () {
    when(() => repository.login(
      email: any(named: 'email'),
      password: any(named: 'password'),
    )).thenAnswer((_) => Future.value(true));
    return bloc;
  },
  seed: () => LoginDataState(
    email: 'example@sample.com',
    password: 'myPass123',
  ) as LoginState,
  act: (_bloc) => _bloc.add(LoginButtonPressed()),
  expect: () => [
    isA<LoginLoadingState>(),
    isA<LoginSuccessState>(),
  ],
  verify: (_) {
    verify(() => repository.login(
      email: any(named: 'email'),
      password: any(named: 'password'),
    )).called(1);
  });
});

Полный код можно посмотреть здесь

Из примера выше видно, что в параметре build, перед тем, как вернуть BLoC, используется Stubbing для функции login. Далее все как и в прошлых тестах, за исключением того, что появился параметр verify. Это функция, которая позволит вызывать verify из библиотеки mocktail.

Что еще умеет blocTest?

В примере выше мы рассмотрели не все возможности библиотеки bloc_test. У метода blocTest есть еще несколько параметров:

• setUp — функция, с помощью которой создаются или пересоздаются зависимости, но рекомендуется делать это в методе setUp из flutter_test

• tearDown — функция, с помощью которой обнуляются зависимости, но рекомендуется делать это в методе tearDown из flutter_test

• wait — параметр, который принимает Duration и после вызова функции act ожидает переданное ему время перед тем, как начать отслеживание состояний

• skip — параметр, который показывает, сколько нужно пропустить состояний вначале.
  Например, из кейса, где мы сначала добавляем пароль, а потом нажимаем на кнопку, можно сделать skip равным 1 и не проверять, что пароль закинулся.

• errors — функция аналогичная expect, но для проверки исключений, которые были выброшены во время работы BLoC. Например, если в add передать null вместо события, или где-то в обработчике попалась необработанная ошибка.

Заключение

В этой статье мы рассмотрели, как можно написать Unit-тесты, чтобы протестировать BLoC в наших Flutter-приложениях.

Всем хорошего кода!

Подписывайтесь на наш авторский телеграм-канал Flutter.Много, чтобы всегда все новости узнавать первыми!