2017-10-29 23 views
0

CQRS 명령의 정의에 따라 유효성을 검사 할 수 있고 마지막에 유효성 검사가 통과하지 않으면 거부됩니다. 내 명령 유효성 검사의 일환으로 상태 전환이 실제로 필요한지 확인합니다. 따라서 간단한 예제를 보겠습니다. 액터가 상태 A에 있습니다. 명령이 액터로 보내져 상태 B로 이동합니다. 명령이 유효화되고 끝 이벤트가 생성됩니다 StateBUpdated. 그런 다음 똑같은 명령이 전송 상태 B로 전송됩니다. 다시 명령 유효성이 검사되고 유효성 검사 중에 이벤트가 생성되지 않는다고 결정됩니다 (이미 상태 B에 있기 때문에). 명령이 처리되었고 모든 것이 처리됩니다. 승인. 그것은 일종의 멱등감 일입니다.akka 영구적 인 액터 테스트 이벤트가 생성되었습니다

그럼에도 불구하고, 나는 이것을 시험하기가 힘들다. 영속 액터에 대한 일반적인 단위 테스트는 액터에 명령을 보내고 액터를 다시 시작하고 상태가 지속되는지 확인하는 것과 같습니다. 얼마나 많은 이벤트가 생성되었는지 확인하라는 명령을 배우에게 보내고 싶습니다. 그렇게하는 방법? 당신도 당신의 지속성을 조롱하거나 않을까에서 쉽게 상태의 액세스 할 수 있어야합니다 같은

감사

답변

0

는 설명에서 들린다. 나는 그것을 할 수있는 두 가지 프로젝트를 발견 할 수 있었다 :

akka-persistence-mock 테스트에 사용하기 위해 설계되었지만 실제로는 개발되지 않았다.

akka-persistence-inmemory 지속적 배우, 지속적인 FSM 및 akka 클러스터를 테스트 할 때 매우 유용합니다

.

필자는 저널의 모든 메시지를 검색 할 수 있기 때문에 후자를 권장합니다.

1

우리는 akka 지속성을 기반으로 내부 CQRS 프레임 워크를 개발하는 동안이 문제에 직면했습니다. 우리의 솔루션은 Persistence Query (https://doc.akka.io/docs/akka/2.5/scala/persistence-query.html)를 사용하는 것이 었습니다. 사용하지 않은 경우 저널 플러그인이 선택적으로 구현할 수있는 쿼리 인터페이스이며 CQRS 시스템에서 읽기 측면으로 사용할 수 있습니다.

테스트 목적으로, 메서드는 eventsByPersistenceId가되어 액터에 의해 지속 된 모든 이벤트가있는 akka 스트림 소스가 제공됩니다. 당신이 스칼라에 참 못생긴 사용되는, 그래서 만약, 위에서 부풀어 보인다

public CompletableFuture<List<Message<?>>> getEventsForIdAsync(String id, FiniteDuration readTimeout) { 
    return ((EventsByPersistenceIdQuery)readJournal).eventsByPersistenceId(id, 0L, Long.MAX_VALUE) 
     .takeWithin(readTimeout) 
     .map(eventEnvelope -> (Message<?>)eventEnvelope.event()) 
     .<List<Message<?>>>runFold(
      new ArrayList<Message<?>>(), 
      (list, event) -> { 
      list.add(event); 
      return list; 
      }, materializer) 
     .toCompletableFuture(); 
} 

죄송합니다, 우리가 사용하는 Java : 소스는 같은 이벤트의 목록으로 접힐 수있다. 점점 readJournal는만큼 간단하다

ReadJournal readJournal = PersistenceQuery.lookup().get(actorSystem) 
    .getReadJournalFor(InMemoryReadJournal.class, InMemoryReadJournal.Identifier()) 

당신은 그것을 테스트에 가장 적합하기 때문에 우리가 akka.persistence.inmemory 플러그인을 사용하여 볼 수 있지만 지속성 쿼리 API가 작동 할 구현하는 플러그인.

우리는 실제로 우리의 프레임 워크 내부의 BDD 같은 테스트 API를 만든, 그래서 일반적인 테스트는 다음과 같습니다

fixture 
    .given("ID1", event(new AccountCreated("ID1", "John Smith"))) 
    .when(command(new AddAmount("ID1", 2.0))) 
    .then("ID1", eventApplied(new AmountAdded("ID1", 2.0))) 
    .test(); 

보시다시피, 우리는 또한 주어진 절에 이전 이벤트를 설정하는 경우를 처리 잠재적으로 여러 persistenceIds (우리는 ClusterSharding 사용)를 처리합니다.