[SPRING] Spring을 테스트 할 때 가양 성을 피하기 위해 이전 플러시의 필요성에 대한 설명이 필요합니까?

Spring을 테스트 할 때 가양 성을 피하기 위해 이전 플러시의 필요성에 대한 설명이 필요합니까?

테스트와 관련한 봄 문서에서,

누군가 내가 플러시를 호출해야하는 이유를 설명 할 수 있습니까?

해결법

1. ==============================

   1.글쎄, 당신은 실제로 재미있는 부분을 건너 뛰었습니다, 예제 :) 여기 있습니다 :

   글쎄, 당신은 실제로 재미있는 부분을 건너 뛰었습니다, 예제 :) 여기 있습니다 :

   // ...
   
   @Autowired
   private SessionFactory sessionFactory;
   
   @Test // no expected exception!
   public void falsePositive() {
       updateEntityInHibernateSession();
       // False positive: an exception will be thrown once the session is
       // finally flushed (i.e., in production code)
   }
   
   @Test(expected = GenericJDBCException.class)
   public void updateWithSessionFlush() {
       updateEntityInHibernateSession();
       // Manual flush is required to avoid false positive in test
       sessionFactory.getCurrentSession().flush();
   }
   
   // ...
   

   이 예제가 설명하려고하는 것은 데이터베이스에서 메모리 내 변경 사항을 동기화하기 위해 실제로 세션 (일차 레벨 캐시라고도 함)을 플러시하지 않는 한 데이터베이스 통합을 실제로 테스트하지 않고 실제 예상되는 동작 또는 실패를 테스트하지 않을 수 있다는 것입니다 문제.

   예를 들어 제약 조건 위반으로 인해 데이터베이스가 오류를 반환 할 수 있으며 데이터베이스에 도달하지 않은 경우 위의 falsePositive () 테스트 메소드에서와 같이 올바른 동작을 나타내지 않습니다. 이 테스트 메소드는 실패하거나 예외가 예상되지만 통과 할 것입니다. 반면에 플러시를 사용하는 다른 테스트 방법은 실제 동작을 테스트합니다. 따라서 플러시 할 필요가 있습니다.

2. ==============================

   2.스프링 문서는 잘못된 개념을 사용합니다. 그것은 분명했습니다

   스프링 문서는 잘못된 개념을 사용합니다. 그것은 분명했습니다

   여기 위키 백과 간다.

   Spring에서 제공 한 샘플을 보면 프로덕션 환경에서 예외 (A GenericJDBCException)가 발생하지만 발견되지 않았습니다. 보려면 일부 ORM 공급자를 사용할 때 기본 커밋을 호출해야합니다.

   XUnit 테스트 패턴 정의

   올바른 개념은 잘못된 것입니다. Negative

   @Test // no expected exception!
   public void falseNegative() {
   

3. ==============================

   3.@Transactional을 사용하여 스프링 테스트에 주석을다는 것은 편리하지만 프로덕션 코드가 실행되는 방식이 아닙니다. @Transactional 주석은 테스트 메소드를 실행하기 전에 트랜잭션을 시작하고 테스트 메소드가 완료되면 트랜잭션을 롤백합니다.

   @Transactional을 사용하여 스프링 테스트에 주석을다는 것은 편리하지만 프로덕션 코드가 실행되는 방식이 아닙니다. @Transactional 주석은 테스트 메소드를 실행하기 전에 트랜잭션을 시작하고 테스트 메소드가 완료되면 트랜잭션을 롤백합니다.

   커밋은 플러시보다 먼저 수행되지만 롤백은 수행되지 않으므로 수동 플러시는 모든 Entity 변경 사항을 SQL 문으로 변환하는 안전 메커니즘입니다.

   보다 적절한 설계는 다음과 같이 명시 적으로 트랜잭션 경계를 그립니다.

   @Test
   public void testRootObjects() {
   
       final Company newCompany = new Company();
       newCompany.setName("TV Company");
   
       final Long companyId = transactionTemplate.execute(new TransactionCallback<Long>() {
           @Override
           public Long doInTransaction(TransactionStatus transactionStatus) {
               entityManager.persist(newCompany);
               return newCompany.getId();
           }
       });
       Company detachedCompany = transactionTemplate.execute(new TransactionCallback<Company>() {
           @Override
           public Company doInTransaction(TransactionStatus transactionStatus) {
               Company attachedCompany = entityManager.find(Company.class, companyId);
               assertEquals(newCompany, attachedCompany);
               assertEquals(newCompany.hashCode(), attachedCompany.hashCode());
               return attachedCompany;
           }
       });
       assertEquals(newCompany, detachedCompany);
       assertEquals(newCompany.hashCode(), detachedCompany.hashCode());
   }
   

   TransactionTemplate은 코드를 커밋하여 수동 플러시가 필요 없습니다.

   인터페이스를 통해 @Transactional 서비스 메소드를 호출하면 TransactionTemplate이 전혀 필요하지 않습니다. 왜냐하면 Spring 프록시가 TransactionInterceptor를 호출하기 때문입니다 (Spring이 트랜잭션 주석을 인식하도록 가정 한 경우). 따라서 트랜잭션이 귀하를 대신하여 시작 / 위탁했습니다.

4. ==============================

   4.누구나 @TransactionConfiguration 주석을 확인 했습니까? 프로젝트에서 구동되는 @Transactional 어노테이션을 사용한다면 테스트 케이스의 @TransactionConfiguration (defaultRollback = false, transactionManager = "YourTransactionManager")을 완벽하게 설정하면된다. 잘하면이 방법이 도움이 될 것이다.

   누구나 @TransactionConfiguration 주석을 확인 했습니까? 프로젝트에서 구동되는 @Transactional 어노테이션을 사용한다면 테스트 케이스의 @TransactionConfiguration (defaultRollback = false, transactionManager = "YourTransactionManager")을 완벽하게 설정하면된다. 잘하면이 방법이 도움이 될 것이다.

from https://stackoverflow.com/questions/3562399/need-explanation-on-the-necessity-of-a-prior-flushing-to-avoid-false-positives-w by cc-by-sa and MIT license