2015-11-03 3 views
4

Я работаю над проектом, основанным на Akka Persistent FSM. В частности:Как протестировать Акка Настойчивый актер

  1. Я хочу знать, как лучше всего структурировать тестовые примеры для независимости? Так как изменения состояния сохраняются (это недостаточно объяснено в документации, но можно увидеть here), это может быть сложно, чтобы мои постоянные участники всегда начинались в чистом состоянии. Нужно ли вручную создавать перезагрузку в протоколе FSM моего актера? Если это так, это кажется не идеальным, поскольку это новое поведение, которое требует тестирования самостоятельно.

  2. Каков наилучший способ управления журналом при тестировании? Есть ли простой способ настроить использование другого журнала для тестирования, не делая этого выбора явно в самом дизайне актера? В разделе документов Plugin TCK упоминается удаление всего файла журнала вручную. Это кажется разумным для тестирования самих плагинов, но похоже на ненужное низкоуровневое решение для кода приложения. Возможно, мне нужно явно обратиться к журналу asyncDeleteMessagesTo в тестовом срыве? Это все еще кажется довольно низким уровнем, но, возможно, это просто инфраструктура, которая еще не была встроена в библиотеку.

ответ

7

При модульном тестировании постоянных участников вы можете использовать плагин сохранения в памяти, например. https://github.com/dnvriend/akka-persistence-inmemory

Нет кода требуются изменения, вы можете просто использовать в src/test/resources другой application.conf, чем в src/main/resources.

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

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

+1

Очень информативный - я продолжу этот метод. Должен ли я дублировать все из моего основного 'application.conf', или я могу просто предоставить переопределения? На данный момент конфигурация журнала - это все, что я делаю, но мне интересно заранее, когда я в конечном итоге добавлю больше настроек. Мне не нравится концепция инъекции 'persistenceId', но если это лучшее, что я могу сделать, тогда это путь. – acjay

+0

@ mattinbits, можете ли вы отправить пример, без необходимости ручного удаления журнала? он обрабатывается плагином inmemory? – SaKou

+0

@SaKou это в природе его пребывания в памяти. Как только процесс умирает, память об этом процессе не сохраняется. – mattinbits

Смежные вопросы