Проверка штормовых болтов и носиков

Наш подход заключается в использовании конструктора-инъекции сериализуемой фабрики в носик / болт. Затем носик / болт консультируется с заводом относительно метода открытия / подготовки. Единственная обязанность фабрики - инкапсулировать получение зависимостей носика / болта сериализуемым способом. Такой дизайн позволяет нашим модульным тестам внедрять фальшивые / тестовые / имитирующие фабрики, которые при обращении к ним возвращают фиктивные сервисы. Таким образом, мы можем узко провести модульное тестирование носика / болтов, используя макеты, например. Мокито.

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

Болт

public class NotifyUserBolt extends BaseBasicBolt {
  public static final String NAME = "NotifyUser";
  private static final String USER_ID_FIELD_NAME = "userId";

  private final UserNotifierFactory factory;
  transient private UserNotifier notifier;

  public NotifyUserBolt(UserNotifierFactory factory) {
    checkNotNull(factory);

    this.factory = factory;
  }

  @Override
  public void prepare(Map stormConf, TopologyContext context) {
    notifier = factory.createUserNotifier();
  }

  @Override
  public void execute(Tuple input, BasicOutputCollector collector) {
    // This check ensures that the time-dependency imposed by Storm has been observed
    checkState(notifier != null, "Unable to execute because user notifier is unavailable.  Was this bolt successfully prepared?");

    long userId = input.getLongByField(PreviousBolt.USER_ID_FIELD_NAME);

    notifier.notifyUser(userId);

    collector.emit(new Values(userId));
  }

  @Override
  public void declareOutputFields(OutputFieldsDeclarer declarer) {
    declarer.declare(new Fields(USER_ID_FIELD_NAME));
  }
}

Тест

public class NotifyUserBoltTest {

  private NotifyUserBolt bolt;

  @Mock
  private TopologyContext topologyContext;

  @Mock
  private UserNotifier notifier;

  // This test implementation allows us to get the mock to the unit-under-test.
  private class TestFactory implements UserNotifierFactory {

    private final UserNotifier notifier;

    private TestFactory(UserNotifier notifier) {
      this.notifier = notifier;
    }

    @Override
    public UserNotifier createUserNotifier() {
      return notifier;
    }
  }

  @Before
  public void before() {
    MockitoAnnotations.initMocks(this);

    // The factory will return our mock `notifier`
    bolt = new NotifyUserBolt(new TestFactory(notifier));
    // Now the bolt is holding on to our mock and is under our control!
    bolt.prepare(new Config(), topologyContext);
  }

  @Test
  public void testExecute() {
    long userId = 24;
    Tuple tuple = mock(Tuple.class);
    when(tuple.getLongByField(PreviousBolt.USER_ID_FIELD_NAME)).thenReturn(userId);
    BasicOutputCollector collector = mock(BasicOutputCollector.class);

    bolt.execute(tuple, collector);

    // Here we just verify a call on `notifier`, but we could have stubbed out behavior befor
    //  the call to execute, too.
    verify(notifier).notifyUser(userId);
    verify(collector).emit(new Values(userId));
  }
}

Начиная с версии 0.8.1 средства модульного тестирования Storm доступны через Java:

• http://storm-project.net/2012/09/06/storm081-released.html

Пример использования этого API можно найти здесь:

• https://github.com/xumingming/storm-lib/blob/master/src/jvm/storm/TestingApiDemo.java

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

Оказывается, довольно легко имитировать объекты шторма, такие как OutputDeclarer, Tuple и OutputFieldsDeclarer. Из них только OutputDeclarer когда-либо видит какие-либо побочные эффекты, поэтому, например, закодируйте фиктивный класс OutputDeclarer, чтобы иметь возможность отвечать на любые испускаемые кортежи и привязки. Затем ваш тестовый класс может использовать экземпляры этих фиктивных классов, чтобы легко настроить экземпляр болта / носика, вызвать его и проверить ожидаемые побочные эффекты.