롤백을 사용할 때 트랜잭션 테스트 메소드가 예외를 throw하지 않음

Question

테스트 방법 remove이 147 인 일부 사용자를 제거하려고 시도했지만이 ID가 존재하지 않습니다. Rollback(false)을 사용하면 예외 (예상되는 동작)가 발생하지만 문제가 없으면 테스트가 통과합니다. 따라서 두 가지 질문이 있습니다.

1. 왜 롤백을 비활성화 할 때만 테스트가 실패합니까?
2. 롤백을 사용하는 예외를 가져올 수 있습니까?

UserDao 클래스 레벨의 주석 (빈 이름) 일반적인 DAO 상기 @Transactional (기본 옵션)이 클래스와 @Repository에서 상속됩니다.

Here 롤백을 사용하지 않도록 설정할 때의 예외입니다.

나는 위에서 아래에서, 스택 추적을 읽고 5.2.10 최대 절전 모드 및 JUnit을 4.12

@RunWith(SpringJUnit4ClassRunner.class) 
@WebAppConfiguration 
@Transactional 
@ContextConfiguration({ 
     "classpath:myapp-config-test.xml", 
     "classpath:hib-test.xml"}) 
public class UserControllerTest { 

    private MockMvc mockMvc; 
    private MvcResult mvcResult; 
    private final String basePath = "https://stackoverflow.com/users/"; 

    @Autowired 
    private UserDao userDao; 

    @Before 
    public void setUp() throws Exception { 
     mockMvc = MockMvcBuilders.standaloneSetup(new UserController(userDao)).build(); 
    } 

    @Test 
    //@Rollback(false) 
    public void remove() throws Exception { 
     mockMvc.perform(delete(basePath + "147")).andExpect(status().isOk()); 
    } 
} 

Answer 1

, 스프링 프레임 워크 4.3.9을 사용하고 있습니다 :

Caused by: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 
    at org.hibernate.jdbc.Expectations$BasicExpectation.checkBatched(Expectations.java:67) 
    at org.hibernate.jdbc.Expectations$BasicExpectation.verifyOutcome(Expectations.java:54) 
    at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:46) 
    at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:3315) 
    at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:3552) 
    at org.hibernate.action.internal.EntityDeleteAction.execute(EntityDeleteAction.java:99) 
    at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:589) 
    at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:463) 
    at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:337) 
    at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39) 
    at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1435) 
    at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:491) 
    at org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3201) 
    at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2411) 
    at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:467) 
    at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.beforeCompletionCallback(JdbcResourceLocalTransactionCoordinatorImpl.java:146) 
    at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.access$100(JdbcResourceLocalTransactionCoordinatorImpl.java:38) 
    at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JdbcResourceLocalTransactionCoordinatorImpl.java:220) 
    at org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:68) 
    at org.springframework.orm.hibernate5.HibernateTransactionManager.doCommit(HibernateTransactionManager.java:582) 
    ... 24 more 

을 당신이 볼 수있는 예외가 트랜잭션 관리자가 트랜잭션을 커밋 할 때 발생합니다.

at org.springframework.orm.hibernate5.HibernateTransactionManager.doCommit(HibernateTransactionManager.java:582) 

트랜잭션 원인 커밋 메모리했고, 계속 된 변화 플러시 할 하이버 네이트 세션 :

at org.hibernate.action.internal.EntityDeleteAction.execute(EntityDeleteAction.java:99) 

그리고 가입일 :

at org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3201) 

그리고 사실은, 플러시는 삭제가 실제로 데이터베이스에서 실행되도록 아무것도 삭제하지 않고 삭제는 예외가 발생합니다 :

org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 

그래서, 실제로 삭제를 실행하고, 예상되는 예외를 발생하기 위해, 당신은 플러시해야합니다.

그러나 MVC 컨트롤러의 단위 테스트에서 DAO의 동작 (그리고 심지어 Hibernate 자체에 의해 이미 테스트 된 Hibernate의 동작)을 테스트해서는 안됩니다. 대신 컨트롤러를 단위 테스팅 할 때 컨트롤러 (예 : DAO)의 종속성을 조롱해야합니다. DAO에 대한 또 다른 테스트를 해보십시오.