SQL 및 데이터 조작 기능이있는 TDD

저는 전문 프로그래머이지만 공식적으로 소프트웨어 엔지니어링 교육을받은 적이 없습니다. 자주 방문하면서 SO를 사용할 때마다 가능할 때마다 단위 테스트를 작성하는 경향을 발견했으며 소프트웨어가 더욱 복잡하고 정교 해짐에 따라 자동화 테스트가 디버깅 지원에 좋은 아이디어라고 생각합니다.

그러나 대부분의 작업에는 복잡한 SQL을 작성한 다음 어떤 방식으로 출력을 처리하는 것이 포함됩니다. 예를 들어 SQL이 올바른 데이터를 반환하는지 확인하기 위해 어떻게 테스트를 작성 하시겠습니까? 그런 다음 데이터를 통제 할 수없는 경우 (예 : 타사 시스템의 데이터), 더미 데이터를 다량으로 쓰지 않고도 처리 루틴을 효율적으로 테스트 할 수있는 방법은 무엇입니까?

내가 생각할 수있는 가장 좋은 해결책은 대부분의 경우를 다루는 데이터를 보는 것입니다. 그런 다음 해당 뷰를 내 SQL과 결합하여 올바른 레코드를 반환하는지 확인하고 뷰를 수동으로 처리하여 함수 등이 제대로 수행되고 있는지 확인할 수 있습니다. 여전히 과도하고 허약 한 것 같습니다. 특히 테스트 할 데이터 찾기 ...

데이터베이스와 관련된 모든 것을 테스트하는 중요한 규칙은 데이터베이스를 나머지 응용 프로그램과 완전히 분리하는 것입니다.

포트와 어댑터 아키텍처는 정말 좋은 예이다. 데이터베이스는 애플리케이션에 대한 어댑터를 통한 외부 플러그인으로 간주됩니다. 모든 타사 하위 시스템도 마찬가지입니다. 앱의 작동 방식을 테스트하고 타사 하위 시스템의 응답을 해석하는 방법을 테스트하는 유일한 방법은이 개별 하위 시스템의 응답을 스텁하는 것입니다. 반드시 모든 데이터 개체를 수동으로 작성해야한다는 의미는 아닙니다. 데이터 기반 테스트를 사용하는 방법을 쉽게 이용할 수 있습니다.

응용 프로그램이 데이터베이스와 상호 작용하는 방법을 테스트하는 것과 같이 데이터베이스 어댑터를 가짜로 만들어 메모리와 같은 데이터베이스를 사용할 수 있습니다.

이제 데이터베이스 쿼리를 테스트하십시오. 우선 모든 복잡한 쿼리를보다 쉽고 간단하며 예측 가능한 쿼리로 분해해야합니다. 뚱뚱한 수업이나 뚱뚱한 기능에 대해서도 마찬가지입니다. Dbunit 과 같은 데이터베이스 테스트에 도움이되는 도구가 있습니다. 내가 때때로 취하는 간단한 접근법은 특성화 테스트 개념을 사용하는 것입니다. 따라서 데이터베이스를 알기 상태로 설정하고 출력 해야하는 모든 쿼리를 장소 (파일, 메모리)에 저장 하고이 출력을 올바른 것으로 간주합니다. 다음 실행은 결과와이 결과를 비교하여 필요한 회귀 테스트를 확실히 제공합니다. 실제로 첫 번째 출력이 정확한 것은 아니지만 회귀 문제는이 방법으로 해결할 수 있습니다. 쿼리를 제대로 분해 한 경우 알려진 상태의 데이터베이스에 대해 개별적으로 테스트 할 수 있습니다.

데이터베이스는 일반적으로 응용 프로그램 단위 테스트 중에 위조 된 부분이기 때문에 흥미로운 질문입니다. 데이터베이스 엔진 자체의 논리가 공급자에 의해 잘 테스트 되기는하지만 쿼리, 스키마 및 저장 프로시 저는 테스트되고 회귀로부터 보호되어야하는 코드입니다. 이것은 종종 TDD가 아닌 통합 테스트에 맡겨집니다.

뷰는 TDD에서 선호되는 테스트 당 하나의 측면에 대한 첫 번째 적색광, 녹색광 자동 테스트를 실제로 빌려주지 않기 때문에 어려운 방법 일 것입니다. 또한 뷰를 사용하면 코드 전에 테스트를 먼저 작성할 수 없습니다. 더 나은 방법은 프로 시저에 "어설 션"논리를 추가 (예 : "if"문 사용)하여 오류의 출력을 테스트 할 수있는 저장 프로 시저를 작성하는 것입니다. 장치를 분리하기 위해 각 장치 테스트에서 한 가지만 테스트하면 SP 방법이 더 적합합니다. 또한 SP를 사용하면 초기 코드를 개발할 때와 나중에 리팩토링시 회귀를 테스트 할 때 전체 스위트를 스크립트로 실행할 수 있습니다.

또한 테스트는 반복 가능해야하며 각 단위 테스트에서 상태가 동일하도록 데이터베이스 상태를 초기화하고 해제하는 스크립트가 필요합니다.

통제 할 수없는 데이터에 대한 질문은 어려운 부분입니다. 나는 가짜 데이터로 그것을 조롱하고 단위 테스트를 위해 가능한 한 예외 및 경계 조건을 테스트하는 것이 좋습니다. 그렇지 않으면 통합 테스팅 범주에 더 들어가게됩니다 (이 또한 좋은 일입니다). 통합 테스트의 경우 타사 데이터에 대해 테스트를 실행하고 초기 출력을 생성하고 후속 테스트 (예 : 리팩토링 후)에서 해당 출력이 알려진 초기 출력을 반복하는지 확인할 수 있습니다.

어느 시점에서 테스트 데이터가 필요합니다. 타사 시스템을 사용하는 경우 스키마가 이미 생성되었지만 향후 변경 사항을 해결해야합니다. 업그레이드 문서에서 이러한 변경 사항을 얻을 수 있지만 데이터베이스 버전을 직접 비교해야 할 수도 있습니다.

예상 결과 세트는 데이터베이스 테이블 또는 외부 파일 / 스프레드 시트에 저장 될 수 있습니다. 나는 심지어 CHECKSUM이 사용되거나 비교되는 것을 보았습니다. 뷰 / 프로 시저를 테스트하면 존재하지 않기 때문에 실패하게됩니다. 그런 다음 최소한 실행하기에 충분한 코드를 사용하여 개체를 생성하고 (SELECT -1 as [wrong_data];) 결과 집합과 일치하지 않으므로 오류가 발생합니다. 일치하면 초록색입니다.

프로젝트 소유자와 함께 작업하여 스프레드 시트에서 보고서를 모의하고 부분 데이터를 만들어 보라고 요청했습니다 (결과 데이터를 테스트 테이블에 넣을 수 있음). 처음에는 약간의 푸시 백이 있었지만 보고서를 만들 겠다는 것을 깨달았으며 어쨌든 확인해야합니다. 이것은 장기적으로 시간을 절약했습니다. 변경 요청을하려면 스프레드 시트를 다시 실행해야합니다. 이제 그들은 "추가하기가 얼마나 어려울까요?"라는 질문에 대답 할 수 있습니다.

데이터베이스 플랫폼이 SQL Server 인 경우 매우 유용한 무료 도구 인 tSQLt가 있습니다.

tSQLt는 Microsoft SQL Server 용 데이터베이스 단위 테스트 프레임 워크입니다. tSQLt는 모든 에디션에서 SQL Server 2005 (서비스 팩 2 필요) 이상과 호환됩니다.

데이터베이스 수준에서 테스트를 성공적으로 구현했습니다.

유용한 주요 요소 중 일부는 다음과 같습니다.

• 가짜 테이블 및 뷰를 사용하여 관련된 설정을 줄일 수있는 기능
• 트랜잭션에서 테스트가 자동으로 실행되므로 쉽게 다시 실행할 수 있습니다.
• 어설 션은 테이블 (실제 및 가짜 모두)을 비교하여 데이터를 쉽게 변경했는지 확인할 수 있습니다.