Модульное тестирование полимерного веб-компонента, использующего firebase

Я пытался настроить автономные модульные тесты для полимерных веб-компонентов, которые используют последнюю версию распределенной базы данных Firebase. Некоторые из моих тестов проходят, но другие, которые выглядят почти идентичными пройденным, не работают должным образом.

Я создал проект на github, который демонстрирует мою конфигурацию, и ниже я приведу еще несколько комментариев.

Пример: https://github.com/doctor-g/wct-firebase-demo< /а>

В этом проекте есть два набора тестов, которые отлично работают. Самый простой — offline-test. , который вообще не использует веб-компоненты. Это просто показывает, что можно использовать автономный режим базы данных firebase для запуска некоторых модульных тестов. В основе этого трюка лежит показанный ниже метод suiteSetup, который я почерпнул из работы nfarina. на firebase-сервере.

suiteSetup(function() {
  app = firebase.initializeApp({
      apiKey: 'fake',
      authDomain: 'fake',
      databaseURL: 'https://fakeserver.firebaseio.com',
      storageBucket: 'fake'
  });
  db = app.database();

  db.goOffline();
});

Все тесты в offline-test пройдены.

Следующий пакет — wct-firebase-demo-app_test.html, которые тестируют одноименный веб-компонент. Этот набор содержит серию модульных тестов, которые настроены как offline-test и проходят успешно. Следуя идее внедрения зависимостей, компонент wct-firebase-demo-app имеет атрибут database, в который передается ссылка на базу данных firebase, и он используется для выполнения всех вызовов firebase. Вот пример из комплекта:

  test('offline set string from web component attribute', function(done) {
    element.database = db;
    element.database.ref('foo').set('bar');
    element.database.ref('foo').once('value', function(snapshot) {
      assert.equal(snapshot.val(), 'bar');
      done();
    });
  });

У меня также есть несколько очень простых методов в компоненте, и в моей попытке провести триангуляцию к разрозненным частям я расскажу о них чуть позже. Достаточно сказать, что этот тест проходит:

test('offline push string from web component function', function(done) {
    element.database = db;
    let resultRef = element.pushIt('foo', 'bar');
    element.database.ref('foo').once('value', function(snapshot) {
      assert.equal(snapshot.val()[resultRef.key], 'bar');
      done();
    });
  });

и поддерживается этой реализацией в wct-firebase-demo-app:

  pushIt: function(at, value) {
    return this.database.ref(at).push(value);
  },

Опять же, все это проходит. Теперь мы подходим к настоящему затруднению. Есть набор тестов для другого элемента, x-element , у которого есть метод pushData:

  pushData: function(at, data) {
    this.database.ref(at).push(data);
  }

Тест для этого метода является единственным тестом в его набор:

  test('pushData has an effect', function(done) {
    element.database = db;
    element.pushData('foo', 'xyz');
    db.ref('foo').once('value', function(snapshot) {
      expect(snapshot.val()).not.to.be.empty;
      done();
    });
  });

Этот тест не проходит. Во время выполнения этого теста в консоли появляется сообщение об ошибке:

    Your API key is invalid, please check you have copied it correctly.

Установив несколько точек останова и пройдясь по выполнению, мне кажется, что эта ошибка возникает после вызова once, но до срабатывания обратного вызова. Обратите внимание, опять же, это не происходит с той же тестовой структурой, описанной выше, что и в wct-firebase-demo-app.

Вот где я застрял. Почему наборы offline-test и wct-firebase-demo-app_test работают нормально, но я получаю эту ошибку ключа API в x-element_test? Единственная другая подсказка, которая у меня есть, заключается в том, что если я скопирую действительный ключ API в свою конфигурацию initializeApp, то вместо этого я получу тестовый тайм-аут.

ОБНОВИТЬ:

Вот (исправленное вместе) изображение моего журнала консоли при запуске тестов.:

Журнал консоли, показывающий неудачный тест

Чтобы проиллюстрировать проблему, поднятую tony19 ниже, вот журнал консоли, где закомментированы только pushData has an effect в x-element_test:

Журнал консоли, показывающий пройденные тесты


person Paul    schedule 29.05.2016    source источник
comment
О, очень полезное наблюдение @tony19! Я доверял выводу wct, не просматривая журналы консоли. Возможно, это больше карточный домик, чем я ожидал.   -  person Paul    schedule 29.05.2016


Ответы (1)


Результаты offline-test явно ложноположительны. Если вы проверите консоль Chrome, offline-test на самом деле выдает ту же ошибку:

введите здесь описание изображения

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

Комментирование всех тестов, кроме offline firebase is ok, показывает, что ошибка все еще возникает, что указывает на suiteSetup(). Еще больше сужая проблему, комментируя 2 из 3 вызовов функций в настройке, мы увидим, что ошибка вызвана вызовом firebase.initializeApp() (и не обязательно связана с once(), как вы подозревали).

Один из обходных путей, который следует рассмотреть, — это обернуть библиотеку Firebase в класс/интерфейс и использовать ее для модульных тестов.

person tony19    schedule 29.05.2016
comment
Это не то же самое поведение, которое я вижу здесь: если я закомментирую все тесты, кроме offline firebase is ok, тогда все будет работать нормально, без каких-либо ошибок API. На самом деле, если я закомментирую только pushData has an effect в x-element_test, то весь пакет запустится без каких-либо предупреждений или ошибок в консоли. - person Paul; 30.05.2016
comment
Мне любопытно, как изменения в x-element_test.html повлияют на offline-test.html. Поведение, которое я вижу, легко воспроизводимо для меня на OSX El Capitan, Chrome 51, при фиксации e5d1d55. - person tony19; 30.05.2016
comment
Также, чтобы уточнить, я запускаю offline-test, открывая offline-test.html. Я предполагаю, что вы используете его по-другому, основываясь на ваших скриншотах. Вы видите разницу, когда открываете этот файл в одиночку? - person tony19; 30.05.2016
comment
Я запускаю тесты через polymer test, который является оболочкой вокруг wct. - person Paul; 31.05.2016
comment
Запустив offline-test.html сам по себе в Chrome, я получаю результат, аналогичный тому, что вы разместили здесь, хотя конкретные ошибки и их размещение отличаются. Вероятно, наиболее важно то, что в вызове getProjectConfig есть 400. Это заканчивается тем, что ваш ключ API недействителен. Хром 51, Линукс Минт 17. - person Paul; 31.05.2016
comment
Кроме того, я бы не стал доверять запуску каких-либо тестов непосредственно в браузере, основываясь на том, что объяснено на странице firebase.google.com/docs/web/: некоторые части Firebase SDK требуют, чтобы ваш веб-сайт обслуживался с сервера, а не из локальной файловой системы. Конечно, эти самые части могут быть тем, что задыхается в моих x-element тестах. - person Paul; 31.05.2016
comment
Пара замечаний, которые могут помочь: 1) Ваш ключ API недействителен ... ошибка исходит от Firebase Auth. При работе в автономном режиме аутентификация не имеет большого значения, поэтому ошибка может быть безобидной. 2) В автономном режиме firebase вызывает события только в том случае, если в этом месте есть полные данные. Поэтому, если вы напишете /foo/bar и прослушаете /foo, вы не получите событие. Но если вы напишете /foo, а затем прослушаете /foo, вы это сделаете. Таким образом, вы можете просто выполнить .set(null) в корневой ссылке после установки Firebase.goOffline(), чтобы убедиться, что везде есть полные данные, и все ваши слушатели сработают. - person Michael Lehenbauer; 15.06.2016