1 Жасмин тестирует состояние сервиса

вопрос создан в Wed, May 8, 2019 12:00 AM

Я новичок в тестировании Jasmine и ищу "лучшую практику" для модульного тестирования сервиса AngularJS с отслеживанием состояния. Большинство руководств, которые я мог найти, фокусировались на тестовых примерах, которые запускают атомарные вызовы служб без сохранения состояния.

Это хорошо соответствует синтаксису Жасмин

it("should do something", function(){ expect(target.doSomething()).toBe... })

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

Давайте представим сервис, подобный этому:

angular.module("someModule").factory("someService", function(){
  return { 
    enqueue: function(item){
      // Add item to some queue
    }
  }
});

Для такой службы имеет смысл проверить, что последовательные вызовы enqueue() обрабатывают элементы в правильном порядке. Это включает в себя написание тестового примера, который несколько раз вызывает enqueue() и проверяет конечный результат (который, очевидно, не может быть достигнут с помощью такой простой службы, как приведенная выше, но это не главное ...)

Что не работает:

describe("Some service", function(){
  // Initialization omitted for simplicity
  it("should accept the first call", function() { 
    expect(someService.enqueue(one)).toBe... // whatever is correct 
  });
  it("should accept the second call", function() { 
    expect(someService.enqueue(two)).toBe... // whatever is correct 
  });
  it("should process items in the correct order", function() { 
    // whatever can be used to test this
  });
});

Приведенный выше код (который на самом деле определяет не один, а три тестовых случая) не выполняется случайным образом, так как три тестовых случая выполняются ... так же, как и случайно.

Плакат в этот поток предложил разделить код на несколько блоков describe, чтобы они выполнялись в указанном порядке, но опять-таки, похоже, что это отличается от одной версии Jasmine к другой (согласно другим авторам) в той же теме). Более того, выполнение наборов и тестов в случайном порядке, кажется, является намеченным способом; даже если бы по настройке было возможно переопределить это поведение, вероятно, это НЕ правильный путь.

Таким образом, похоже, что единственный правильный способ тестирования сценария с несколькими вызовами - это сделать ОДИН тестовый пример, например:

describe(("Some service", function(){
  // Initialization omitted for simplicity
  it("should work in my complex scenario", function(){
    expect(someService.enqueue(one)).toBe... // whatever is correct 
    expect(someService.enqueue(two)).toBe... // whatever is correct 
    expect(/* whatever is necessary to ensure the order is correct */);
  });
});

Хотя с технической точки зрения это кажется логичным путем (в конце концов, сложный сценарий - это один тестовый пример, а не три), шаблон «описание + код» Жасмина в этой реализации выглядит нарушенным как:

  • Нет способа связать сообщение с каждым "подэтапом", которое может завершиться неудачей в тестовом примере;
  • Описание единственного "it" неизбежно громоздко, как в примере выше, чтобы действительно сказать что-то полезное о сложном сценарии.

Это заставляет меня задуматься, является ли это единственно правильным решением (или не так ли?) для такого рода потребностей тестирования. Опять же, я особенно заинтересован в том, чтобы «делать это правильно», а не использовать какой-то хак, который заставил бы его работать ... там, где он не должен.

    
0
1 ответ                              1                         

К сожалению нет кода для этого ... Не уверен, что это нужно, я думаю, вам просто нужно скорректировать свои ожидания от ваших тестов.

Что касается общего правила тестирования, то вам неважно, как внешние зависимости обрабатывают сервис, вы не можете это контролировать. Вы хотите проверить, как вы думаете, ожидаемые результаты будут к вашим услугам.

Для вашего примера вы просто захотите вызвать зависимости для вашей службы, вызвать функцию и проверить ожидаемые результаты от вызова функции enqueue. Если он возвращает обещание, проверьте успех и ошибку. Он вызывает проверку API и т. Д.

Если вы хотите увидеть, как внешние зависимости используют ваш сервис, вы протестируете его на этих тестах зависимостей.

Например, у вас есть контроллер, который вызывает enqueue. В тесте вам нужно будет ввести вашего провайдера (службу). И справиться с ожиданиями.

    
0
2019-05-08 19: 54: 34Z
источник размещен Вот