Создание интеграционных тестов в Ember 2.16, использующих window.confirm ()? - PullRequest
Новая
       20

Создание интеграционных тестов в Ember 2.16, использующих window.confirm ()?

2 голосов
/ 18 октября 2019

Я пишу интеграционные тесты для компонента Ember 2.16 и тестирую некоторые пользовательские действия.

Одно из действий пользователя вызывает window.confirm(), где пользователя спрашивают, уверены ли они, что хотят удалитьэлемент перед удалением элемента.

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

delete(id){
  if(confirm('Are you sure you want to delete?')){
    //do stuff
  } else {
    //do other stuff
  }
}

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

[Testem] Calling window.confirm() in tests is disabled, because it causes testem to fail with browser disconnect error.

Как я могу создать интеграционный тест, который будет обходить функциональность window.confirm()?

Я добавил в свой компонент способ обойти подтверждение, если env находится в "тестовом" режиме,но это не очень помогает, так как я не тестирую часть кода, которая опирается на window.confirm().

Я посмотрел вокруг, чтобы посмотреть, есть ли переменная, которую я могу передать компоненту, чтобы сделать window.confirm() true / false, но безуспешно.

Как создать тест, который будет проверять компонент, вызывающий window.confirm() внутри действия?

Ответы [ 2 ]

1 голос
/ 18 октября 2019

Одним из решений было бы сохранить исходную реализацию window.confirm и написать собственную реализацию перед тестом, а затем восстановить исходную реализацию в конце теста.

Вот как я бы это сделал: 

// Watch out, this test is written with the latest ember-qunit syntax which might not be exactly what you have in your Ember 2.16 application
import { module, test } from 'qunit';
import { setupRenderingTest } from 'ember-qunit';
import { render } from 'ember-test-helpers';
import hbs from 'htmlbars-inline-precompile';

module('your component integration tests', function(hooks) {
  setupRenderingTest(hooks);

  test('clicking the OK confirm button', async function(assert) {
    // save the original window.confirm implementation
    const originalWindowConfirm = window.confirm;

    // simulate the OK button clicked
    window.confirm = function() { return true;}

    // ADD YOUR TEST AND ASSERTIONS HERE

    // restore the original window.confirm implementation
    window.confirm = originalWindowConfirm;
  });

});
0 голосов
/ 18 октября 2019

Я бы заглушил window.confirm() в тесте с библиотекой вроде sinon , где я ожидаю, что он будет вызван так, что:

  1. надеюсь, что сообщение об ошибке не появится
  2. Я знаю, confirm() на самом деле вызывается кодом и делает то, что я хочу, чтобы он делал в точности (т. Е. Я могу сделать это простым fn)
  3. его можно восстановить, поэтому предупреждениесообщение будет зарегистрировано в других тестах (что полезно)

В соответствии с кодом теста оно перезаписывает window.confirm(), чтобы напечатать это предупреждение: 

window.confirm = function() {
  throw new Error('[Testem] Calling window.confirm() in tests is disabled, because it causes testem to fail with browser disconnect error.');
};

Выполнение чего-либо подобного в тесте с sinon должно работать: 

const confirm = sinon.stub(window, "confirm").callsFake(() => {
  // fake implementation here which overwrites the testem implementation
});

// rest of the test

confirm.restore(); // restores the testem implementation
...