한빛출판네트워크

    

        
        
        
        
        
        
        
                
      {call insert_order(?, ?, ?)}
      {call update_order(?, ?, ?)}
      {call delete_order(?)}
                
    

• 데이터 다양성(Data diversity) 테스트 데이터가 확실히 (외래키 관계와 빈(null) 값과 같은)모든 종류의 데이터 시나리오를 반영하고 있는지 확인합니다.
• 데이터셋 규모(Dataset size) 물론 여러분의 모든 테스트를 지원하기 위한 상당히 많은 데이터를 유지하는 것은 중요하지만 DBUnit을 사용하여 모든 테스트 메소드 마다 데이터를 지우고 다시 읽어 들일 수 있다는 것을 기억하시기 바랍니다. 상당히 많은 데이터는 테스트를 느리게 만듭니다.

• Find All DAO가 예상한 만큼의 row의 개수를 반환하는지 확인
• Find one 가상 주키를 사용하여 레코드를 가져오고 가져온 레코드의 모든 값(컬럼)들이 예상한 값들과 같은지 확인
• Insert 레코드 하나를 추가하고 추가 되었는지 확인
• Insert multiple records 한 번에 하나 이상의 레코드를 추가하는 것이 제대로 동작하는지 확인
• Insert duplicates 가상 주키의 제약 사항을 어기는 것을 시도
• Delete 레코드를 삭제해보고 진짜로 제거 되었는지 확인
• Delete multiples 여러분이 설계한 DAO가 이 기능을 지원할 때 해보세요.
• Update 수정을 하고 DB에 수정된 내용이 영속화 되었는지 확인
• Violate constraints 모든 가능한 가상 제약들을 테스트했는지 확인
• Optimistic locking 낙관적인 롹킹 예외(optimistic locking)를 발생할 수 있는 몇 가지 방법들이 있습니다. 낙관적인 롹킹 예외가 제대로 동작하는지 확인하려면 다음의 네 가지 조건을 확인해봐야 합니다.
  • 이미 삭제한 레코드를 삭제하려고 할 때
  • 최근 팻치(fetch)로 수정된 레코드를 삭제하려고 할 때(이 것은 버전 컬럼을 사용할 때 가능합니다.)
  • 삭제된 레코드를 수정하려고 할 때
  • 최근 팻치(fetch)로 삭제된 레코드를 수정하려고 할 때(이 것은 버전 컬럼을 사용할 때 가능합니다.)

1. Develop tables: These will look much like your views, but will have real foreign keys and indexes. Make sure to maintain the same column names as the views themselves.
2. 테이블 만들기 : 뷰와 상당히 비슷하게 만들어지겠지만 진짜 외래키와 인덱스를 가지고 있습니다. 뷰와 같은 컬럼 이름을 사용하는지 확인하기 바랍니다.
3. Load tables: You will load the tables with data from your already existing views. Select from view into table. It"s really that simple.
4. 테이블 로딩하기 : 기존의 뷰에 이미 존재하는 데이터를 가지고 테이블을 로딩합니다. 뷰에서 테이블로 선택을 변경 합니다. 실제로 간단합니다.
5. 맵핑 파일 수정하기 : 하이버네이트 맵핑을 변경하여 뷰 대신에 테이블을 사용하고, 만약 스토어드 프로시저를 사용한다면 , 와 엘리먼트르르 제거합니다.(더 이상 필요 없기 때문이죠.)
6. 테스트, 테스트, 테스트 : 기존의 테스트들은 절대로 수정할 필요가 없습니다. 그것들을 계속하여 다시 실행하면서 검증하면 됩니다.

• 제로 임팩트(Zero impact) DMA 솔루션은 기존의 애플리케이션이나 프로세스에 영향을 주면 안됩니다. 이 말은 새로운 (가상) 데이터 모델이 변경 되면 실제 (결함이 있는 데이터 모델의) 데이터도 변경되어야 한다는 것입니다.
• 기능성 유지 새로운 데이터 모델이 특정 컬럼의 중요성을 제거 하더라도 지속적으로 예전의 행위를 유지할 수 있어야 하는 것이 중요합니다. 계산되는 필드가 이에 가장 적합한 예입니다. 만약에 기존 애플리케이션이 추가하기 전에 계산을 하지만 새로운 모델은 심지어 해당 필드를 가지고 있지 않다면 DMA 솔루션은 기존의 행위를 보장해야 하며 필드를 계산해야 합니다. (그리고 추가도 해야겠죠.)
• 완벽한 자신감을 위한 테스트 DMA 솔루션은 충분히 테스트해야 새로운 스키마가 기존의 데이터베이스 스키마만큼 튼튼하다는 자신감을 가질 수 있습니다. DMA 패턴은 단순하게 테이블과 컬럼을 맵핑하는 것이 아니기 때문에 버그가 생기기 쉽습니다. 시도를 한 다음 테스트를 토해서 솔루션이 제대로 됐으며 완벽한 ACID 원칙들을 보장하는지 확인할 수 있습니다.

• 이 기사를 위한 예제 코드
• 하이버네이트에 대해 좀 더 자세한 정보
• MySQL에서 스토어드 프로시저를 작성하는 가이드를 제공하는 MySQL 문서