0
우리는 TSQL 저장 프로 시저에 상당히 많은 논리를 가지고 있습니다. 자동화 된 테스트의 열렬한 팬이기 때문에 필자는 저장 프로 시저에 대한 자동화 된 테스트를 작성하기 시작했습니다.저장 프로 시저의 논리 테스트
C# 프로젝트에서 저장 프로 시저를 호출하여 저장 프로 시저를 테스트합니다. 데이터베이스를 만지는 모든 테스트를 기본 클래스에서 상속하면 커밋되지 않은 TransactionScope에서 테스트가 실행됩니다. 이 문제와 관련된 몇 가지 문제가 있습니다 :
- 테스트는 데이터베이스에 손을 대지 않는 테스트에 비해 느리지 만 생각보다 많이 할 수는 없습니다.
- 때때로 테스트 로직을 실행하기 전에 데이터베이스를 필요한 상태로 만들려는 경우 FK 문제가 발생합니다. 예 : FK에서 참조하는 테이블을자를 필요가있을 때 그렇게 할 수 없습니다. 참조하는 테이블의 행을 제거해야합니다.
- 때로는 새로운 저장 프로 시저 또는 쿼리를 작성하여 필요한 상태로 데이터베이스를 가져와야합니다. 반면에 나는 어쨌든 새로운 기능을 위해 유사한 절차가 필요합니다.
이러한 단점에도 불구하고 스토어드 프로 시저 로직에 상당히 많은 로직이 있으므로 스토어드 프로 시저 로직 테스트를 작성하기로 선택합니다. TSqlUnit과 같은 완전히 다른 접근 방식을 사용하고 있습니까? 아니면 sprocs 테스트를 거치지 않아도됩니까?
이 저장 프로 시저가 상대적으로 작은 값의 통증이 많이 있습니다 이유의 편리한 목록입니다. –
나는 SP 캠프에서 확고하게 자리를 잡았지만 내 마음은 바뀌었다. CRUD에 저장된 procs는 단지 성가신 일입니다. OR 매퍼와 매개 변수화 된 인라인 쿼리 저장 프로 시저가 덜 중요해 보입니다. – vfilby
불행히도 SPs는 내가 사용하도록 구속되어 있으며 변경되지 않을 것입니다. 나는 두려워합니다. – trendl