Полный гайд по тестированию на Flutter. Часть 4: продвинутое модульное тестирование

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

И перед тем, как приступить к самой статье, приглашаю вас в телеграмм-канал Flutter.Много. Мы ведем его всей командой мобильных разработчиком Amiga и рассказываем о личном опыте, делимся полезными плагинами\библиотеками, переводами статей и кейсами. В нашем сообществе уже 2632 участников, присоединяйтесь и вы!

В предыдущей статье мы рассмотрели использование техник Mocking и Stubbing для тестирования классов, которые зависят от других классов. В новом выпуске будет еще больше усложнен класс LoginViewModel при помощи создания переменной _cache для кеширования результата, полученного от SharedPreferences. При вызове функции login, ставится высший приоритет получению данных из кеша.

import 'package:shared_preferences/shared_preferences.dart';

class LoginViewModel {
  final SharedPreferences sharedPreferences;

  LoginViewModel({
    required this.sharedPreferences,
  });

  final Map<String, String?> _cache = {};

  bool login(String email, String password) {
    if (_cache.containsKey(email)) {
      return password == _cache[email];
    }

    final storedPassword = sharedPreferences.getString(email);
    _cache[email] = storedPassword;

    return password == storedPassword;
  }
}

В коде выше содержится ошибка: переменная _cache является приватной, поэтому ее нельзя подменить. Из-за этого остается только один тестовый сценарий – когда _cache пуст. Как можно добавить больше значений к _cache для проверки разных сценариев, сохраняя переменную приватной? Для этого понадобится аннотация @visibleForTesting.

Аннотация @visibleForTesting

final Map<String, String?> _cache = {};

// Expose this method for testing purposes to set values in _cache
@visibleForTesting
void putToCache(String email, String? password) {
  _cache[email] = password;
}

Когда функция помечена аннотацией, подразумевается, что ее следует использовать только в файлах с тестами и внутри файла, содержащего эту функцию. Именно таким образом она остается приватной.

Теперь, напишем тесты для 2 следующих тестовых сценариев:

group('login', () {
  test('login should return true when the cache contains the password input even when the password is incorrect', () {
    // Arrange
    final mockSharedPreferences = MockSharedPreferences();
    final loginViewModel = LoginViewModel(
      sharedPreferences: mockSharedPreferences,
    );
    String email = '[e-mail]';
    String password = 'abc';

    loginViewModel.putToCache(email, 'abc'); // NEW

    // Stubbing
    when(() => mockSharedPreferences.getString(email))
        .thenReturn('123456');

    // Act
    final result = loginViewModel.login(email, password);

    // Assert
    expect(result, true);
  });

  test('login should return false when the cache does not contain the password input and the password is incorrect', () {
    // Arrange
    final mockSharedPreferences = MockSharedPreferences();
    final loginViewModel = LoginViewModel(
      sharedPreferences: mockSharedPreferences,
    );
    String email = '[e-mail]';
    String password = 'abc';

    // Stubbing
    when(() => mockSharedPreferences.getString(email))
        .thenReturn('123456');

    // Act
    final result = loginViewModel.login(email, password);

    // Assert
    expect(result, false);
  });
});

Тест кейсы, связанные с переменной _cache, проверены. Далее попробуем отрефакторить код, чтобы избежать дублирования. Для этого вынесем инициализацию mockSharedPreferences и loginViewModel за пределы тестовых функций.

Когда прогоним тест снова, второй тест упадет с ошибкой.

Почему актуальный результат получился true вместо false?

Когда шарится объект loginViewModel, также шарится и переменная _cache. В первом тест кейсе значение кладется в _cache через loginViewModel.putToCache(email, 'abc');, поэтому когда переходим ко второму тестовому кейсу, _cache уже содержит значение 'abc'. Таким образом, _cache содержит входные данные пароля и возвращает true.

Чтобы исправить баг, нужно удостовериться, что каждый раз, когда прогоняется новый тест, создается новый объект loginViewModel. Это можно сделать, используя функцию setUp.

void main() {
  late MockSharedPreferences mockSharedPreferences;
  late LoginViewModel loginViewModel;

  setUp(() {
    mockSharedPreferences = MockSharedPreferences();
    loginViewModel = LoginViewModel(
      sharedPreferences: mockSharedPreferences,
    );
  });

  ...
}

Полный исходный код

Прогнав тест еще раз, видно, что все тесты прошли.

Функции setUp, tearDown, setUpAll, tearDownAll

• setUp

Функция setUp вызывается перед запуском каждого теста, поэтому она обычно используется для инициализации объектов для теста и конфигурации начальных значений. В примере выше порядок вызова функций выглядит так:

setUp (initialization) -> test case 1 -> setUp (re-initialization) -> test case 2

Таким образом, loginViewModel перед запуском второго тест кейса инициализируется заново, поэтому баг был пофикшен.

• tearDown

Функция tearDown вызывается после завершения каждого теста. Обычно ее используют для задач по очистке, таких как освобождение памяти, закрыть какие-либо ресурсы или закрыть соединение с базой данных.

• setUpAll

Функция setUpAll вызывается всего один раз перед прогоном абсолютно всех тестов. Ее часто используют для открытия соединения с базой данных и дальнейшего использования одной базы данных для всех тестов.

setUpAll(() async {
  await Isar.initializeIsarCore(download: true);
  isar = await Isar.open([JobSchema], directory: '');
});

• tearDownAll

Функция tearDownAll тоже выполняется всего один раз после завершения всех тестов, поэтому часто используется для закрытия доступа к базе данных.

tearDownAll(() async {
  await isar.close();
});

Далее пройдемся по нескольким примерам, чтобы понять, как применять эти 4 функции. Кроме этого, рассмотрим, как проверять Stream’ы.

Тестирование Stream’ов

Представим, что приложение использует базу данных Isar, и в ней есть таблица JobData.

import 'package:isar/isar.dart';
part 'job_data.g.dart';

@collection
class JobData {
  Id id = Isar.autoIncrement;
  late String title;
}

Также есть класс HomeBloc. В этом классе будем слушать данные, которые возвращает Isar.

class HomeBloc {
  HomeBloc({required this.isar}) {
    _streamSubscription = isar.jobDatas
      .where()
      .watch(fireImmediately: true)
      .listen((event) {
        _streamController.add(event);
      });
  }

  final Isar isar;
  final _streamController = 
        StreamController<List<JobData>>.broadcast();
  StreamSubscription? _streamSubscription;
  Stream<List<JobData>> get data => _streamController.stream;

  void close() {
    _streamSubscription?.cancel();
    _streamController.close();
    _streamSubscription = null;
  }
}

Теперь создадим файл для теста, чтобы проверить геттер data из класса HomeBloc.

После этого инициализируем HomeBloc в функции setUp и базу данных Isar в функции setUpAll. Обычно, если инициализируем объект в функции setUp, то он будет очищен в функции tearDown. И наоборот, если мы инициализируем объект в функции setUpAll, то он очистится только в функции tearDownAll.

void main() {
  late Isar isar;
  late HomeBloc homeBloc;

  setUp(() async {
    await isar.writeTxn(() async => isar.clear());
    homeBloc = HomeBloc(isar: isar);
  });

  tearDown(() {
    homeBloc.close();
  });

  setUpAll(() async {
    await Isar.initializeIsarCore(download: true);
    isar = await Isar.open(
      [JobDataSchema],
      directory: '',
    );
  });

  tearDownAll(() {
    isar.close();
  });
}

Наконец, напишем тесты для геттера data.

test('data should emit what Isar.watchData emits', () async {
  expectLater(
    homeBloc.data,
    emitsInOrder([
      [],
      [JobData()..title = 'IT'],
      [JobData()..title = 'IT', JobData()..title = 'Teacher'],
  ]));

  // put data to Isar
  await isar.writeTxn(() async {
    isar.jobDatas.put(JobData()..title = 'IT');
  });
  await isar.writeTxn(() async {
    isar.jobDatas.put(JobData()..title = 'Teacher');
  });
});

Здесь появляется 2 новых вещи:

• Функция expectLater: Она отличается от функции expect, которая используется для проверки синхронных значений, а expectLater — для тестирования асинхронных значений, таких как Stream.
  Когда тестируем поток данных, нужно разместить выражение expectLater до того, как данные попадут в Stream. Таким образом можно следить за значениями, как только они попадают в поток. И не нужно использовать await перед функцией expectLater(), так как тест провалится.

• Функция emitsInOrder - Matcher, который используется для проверки, что данные в Stream попадают в верном порядке. Если нужно проверить все события, но вне зависимости от их порядка, можно использовать Matcher emitsInAnyOrder.

Функция resetMocktailState

Используется для сброса Mock-объектов. Для ошибки выше можно вызвать ее в методах setUp или tearDown для исправления бага вместо инициализации Mock-объекта заново в функции setUp.

tearDown(() {
  resetMocktailState();
});

Заключение

Надеемся, что перевод этой статьи был для вас полезен  и вы научились писать продвинутые тесты на различные сценарии. В следующей части продолжим изучать библиотеку mocktail для написания тестов для более комплексных кейсов.

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