저장 프로 시저의 단위 테스트


44

나는 이것을 꽤 오랫동안 고려 해왔다.

기본적인 질문은 저장 프로 시저를 단위 테스트하는 방법입니다.

고전적인 의미에서 함수에 대해 단위 테스트를 상대적으로 쉽게 설정할 수 있음을 알았습니다 (제로 이상의 인수를 얻고 값을 반환합니다). 그러나 내가 어딘가에 행을 삽입하는 것처럼 보이는 간단한 절차의 실제 예를 고려하면, 몇 번의 트리거로이를 수행하고 삽입 전후에 트리거를 수행하면 '단위'의 경계를 정의하는 것조차 매우 어렵습니다. INSERT자체 만 테스트해야합니까 ? 비교적 간단합니다. 상대적으로 가치가 낮습니다. 전체 이벤트 체인의 결과를 테스트해야합니까? 이것이 단위 테스트인지 아닌지에 대한 질문 외에도 적절한 테스트를 디자인하는 것은 많은 추가 물음표가 발생하는 데 상당한 노력이 될 수 있습니다.

그리고 끊임없이 변화하는 데이터의 문제가 발생합니다. UPDATE단지 몇 개 이상의 행에 영향을 미치는 경우 영향을받는 모든 행을 테스트 사례에 포함시켜야합니다. DELETEs 등의 추가 어려움 .

그렇다면 저장 프로 시저를 어떻게 단위 테스트합니까? 완전히 절망적 인 복잡성에 대한 한계가 있습니까? 유지 관리에 필요한 리소스는 무엇입니까?

편집 AlexKuznetsov의 답변을 기반으로 한 작은 질문이 하나 더 있습니다. 아니면 완전히 쓸모없는 보물이 있습니까?

답변:


32

우리는 거의 5 년 동안이 작업을 해왔으며, 명시 적으로 수정 테스트는 확실히 가능하지만 속도는 느리다고 생각합니다. 또한 별도의 데이터베이스를 사용하지 않으면 여러 연결에서 이러한 테스트를 동시에 쉽게 실행할 수 없습니다. 대신 수정을 암시 적으로 테스트해야합니다. 수정을 사용하여 적어도 일부 테스트 데이터를 작성하고 선택 결과가 예상 결과를 반환하는지 확인합니다.

Close That Loopholes : Unit Testing T-SQL에서 배운 교훈블로그 게시물 이라는 제목의 기사를 작성했습니다 .

"완전히 희망이없는 복잡성에 대한 한계가 있습니까?"라는 질문에 대해 복잡한 모듈은 단순한 것보다 훨씬 더 많은 테스트가 필요합니다.

유지 보수를 단순화하기 위해 예상 결과를 생성하고 별도의 파일로 저장하므로 큰 차이가 있습니다.


15

예, 전체 이벤트 체인을 하나의 단위로 테스트해야합니다. 따라서 테이블에 삽입하고 여러 트리거를 발생시키는 프로 시저가있는 예에서는 다양한 입력에 대한 프로 시저를 평가하는 단위 테스트를 작성해야합니다. 각 단위 테스트는 올바른 값을 반환하고, 테이블 상태를 올바르게 변경하고, 올바른 전자 메일을 생성하며, 그렇게하도록 설계된 경우 올바른 네트워크 패킷을 전송하는지 여부에 따라 통과 또는 실패해야합니다. 간단히 말해서 모든 효과를 확인해야합니다.

단위 테스트를 설계하는 데 약간의 작업이 필요하지만, 대부분 수동으로 단위를 테스트하려면 해당 단위를 테스트하는 데 필요한 작업을 저장하기 만하면됩니다. 마찬가지로 철저하고 훨씬 쉬울 수 있습니다.

데이터를 변경하면 테스트가 더 어려워 지지만 테스트가 덜 중요해지지 않고 실제로 단위 테스트의 가치가 높아 지므로 단위를 변경할 때마다 대부분의 어려움을 한 번만 생각하면됩니다. 저장된 데이터 세트, 설정 / 삭제의 일부인 삽입 / 업데이트 / 삭제 및 범위가 좁은 작업을 모두 사용하면이 작업을보다 쉽게 ​​수행 할 수 있습니다. 질문은 데이터베이스에 국한되지 않기 때문에 세부 사항은 다양합니다.

하이 엔드 또는 로우 엔드에는 복잡성 임계 값이 없으므로 테스트 또는 단위 테스트를 중단해야합니다. 다음 질문을 고려하십시오.

  1. 항상 버그가없는 코드를 작성하십니까?
  2. 작은 단위는 항상 버그가 있습니까?
  3. 큰 유닛에 버그가있는 것이 괜찮습니까?
  4. 재난을 일으키는 데 몇 개의 버그가 있습니까?

새 작업을 시작하고 여러 곳에서 사용되는 작은 기능을 최적화해야한다고 가정합니다. 전체 응용 프로그램은 아무도 기억하지 못하는 직원이 작성하고 유지 관리했습니다. 이 장치에는 정상적인 예상되는 동작을 설명하는 문서가 있지만 그 밖의 내용은 거의 없습니다. 이 중 어느 것을 찾으시겠습니까?

  • 응용 프로그램의 어느 곳에서도 단위 테스트가 없습니다. 변경 한 후에는 장치 자체에 대해 일부 수동 테스트를 수행하여 문서의 예상 값이 여전히 리턴되는지 확인할 수 있습니다. 그런 다음 프로덕션 환경으로 배포하고 손가락을 엇갈리게하고 작동하도록 기대하십시오 (결국 항상 버그가없는 코드를 작성하고 한 단위로 최적화하면 다른 단위에는 영향을 미치지 않을 것입니다). 직접 또는 간접적으로 영향을받는 모든 장치를 수동으로 테스트 할 수 있습니다.
  • 매일 또는 요청시 자동으로 실행되는 응용 프로그램 전체의 단위 테스트. 일반 입력 값과 예상 응답뿐만 아니라 비정상 값과 예상되는 예외도 확인합니다. 3 개의 다른 장치가 더 이상 예상 결과를 반환하지 않는 것을 즉시 확인하여 응용 프로그램에 대한 단위 테스트 스위트를 변경하고 실행하십시오. 그중 두 가지가 양성이므로이를 설명하기 위해 단위 테스트를 조정하십시오. 세 번째는 약간의 수정과 작은 단위 테스트가 필요합니다. 변경 후 전체 테스트 세트가 성공하고 변경 내용을 자신있게 배포 할 수 있습니다.

1
첫째, 귀하의 답변에 감사드립니다-나는이 질문에 대한 더 이상의 발전을 기대하지 않았습니다 ... 둘째, 나는 당신이 간단한 작업에 대해 옳다는 것을 인정해야합니다 .2 열 INSERT조차도 버그를 생성 할 수 있습니다. 열 순서가 인수와 일치하도록 작성되면 괜찮을 수도 있지만 다시 맞습니다. 전체 응용 프로그램을 테스트 체제에 유지하는 것이 좋습니다.
dezso 2013

@dezso 데이터베이스 세계에서 더 많은 노출이 필요한 훌륭한 질문이자 개념입니다.
레이 리펠

"이벤트의 전체 체인을 하나의 단위로 테스트해야합니다"– 이것은 당신이 말할 수있는 가장 반 직관적 인 것입니다. 그런 경우에는 단위가 아닙니다. 통합 테스트를 수행하고 있습니다
Joe Phillips

@Joe Philips-원하는대로 호출하고 삽입을 수행하고 몇 번의 트리거를 발생시키는 절차가 자동화 된 테스트를 수행하는 데 필요한 것으로 간주하는지 확인하십시오.
레이 리펠

8

PostgreSQL의 경우 pgTAP를 확인하십시오 .

pgTAP는 psql 스크립트 또는 xUnit 스타일 테스트 함수로 TAP 방출 단위 테스트를 쉽게 작성할 수있는 데이터베이스 함수 모음입니다.


감사합니다 누구도 경험이 있습니까?
dezso

예, 요즘 꽤 많은 사람들이 있습니다. 궁금한 점이 있으면 메일 목록을 구독하십시오 .
이론

6

스토어드 프로 시저 테스트가 SQL에서 완전히 수행되도록하려면 http://tsqlt.org/를 참조하십시오.

MS SQL 2005 SP2 이상과 호환되며 개발자가 테스트를 구현하기 위해 C # 또는 다른 언어를 알 필요가 없다는 이점이 있습니다.

재실행 가능한 테스트 스위트를 달성하는 데 도움이되는 모의 테이블 및 뷰를 수행하는 기능도 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.