Асинхронное выполнение шага с огурцом-

Question

JVM Рассмотрим следующий сценарий огурец: -

Scenario: Test payment 
Given I login to terminal 
When POS token is generated asynchronously 
Then user generates mobile token 
And payment is successful 

Стадию «POS маркер генерируется асинхронно» необходимо выполнить асинхронно и не должен блокировать выполнение последующих шагов после него. Я смог сделать это с помощью FutureTask в Java. Однако в случае сбоев я не могу утверждать неудачи. Ниже приведен фрагмент кода

@When("^POS token is generated asynchronously$") 
public void gs_Consumer() throws Throwable { 

    HashMap<String, Object> m = DataContainer.getDataMap(); 

    ExecutorService executor = Executors.newFixedThreadPool(2); 
    FutureTask<Object> futureTask1 = null; 

    futureTask1 = new FutureTask<Object>(new Callable<Object>() { 

     public Object call() throws Exception { 

      DataContainer.setDataMap(m); 

      try { 
       retrieve_consumer_information(); 
      } catch (Throwable e) { 
       DataContainer.getDataMap().put("exception", e); 
       throw new Exception(e); 
      } 
      return null; 
     } 
    }); 

    executor.execute(futureTask1); 

    DataContainer.getDataMap().put("response", futureTask1); 
    // Shutdown the ExecutorService 
    executor.shutdown(); 
} 

Тогда я получаю ответ в загробной метода, так как я не могу сделать futureTask1.get() внутри этого метода, как он будет блокировать выполнение от выполнения других последующих стадиях.

public void afterAsynchMethod() { 

    try { 
     ((FutureTask<Object>) DataContainer.getDataMap().get("response")).get(); 
    } catch (InterruptedException | ExecutionException e) { 
     // TODO Auto-generated catch block 
     Assert.fail(e.getMessage()); 
    } 

} 

Теперь, если исключение происходит в методе After, сценарий по-прежнему не отражается как неудачный сценарий. Как я могу отказаться от сценария в этом случае или любых других способов сделать это?

Answer 1

В этом сценарии много деталей. Я бы подумал о том, чтобы вытащить детали в стек. Можно скрыть столько, сколько я могу в классе-помощнике, который будет использоваться для этого шага.

Возможность может быть

Scenario: Thomas pays for a yearly support subscription 
Given Thomas has payed 150 EUR with his credit card 
When the payment is confirmed 
Then he should get a receipt 

Это говорит больше об ожидаемом поведении, а не реализации. Томасу все равно, является ли служба асинхронной или нет.

Но как насчет реализации? Реализация должна учитывать асинхронный характер проблемы. Но не сценарий. Сценарий должен описывать только желаемое поведение.

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

Я бы создал заглушку, которая отвечает за реальный сервис для данного вызова. Штук будет реагировать очень медленно и никогда не сломал сеть, останавливая его. Это избавит вас от необходимости обрабатывать асинхронное поведение.

Тогда я бы выполнил интеграционный тест, который вызывает реальную службу с тем же аргументом, что и вызываемый. И ожидайте те же причины от внешней службы, что и заглушка, жестко закодированная для ответа. Это не было бы испытанием, связанным с бизнесом, и поэтому я бы не описал это с использованием метода Gherkin. Я бы, вероятно, реализовал его с использованием JUnit или аналогичной структуры тестирования.

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