웹 응용 프로그램을 사용한 단위 / 통합 테스트에 대해 다른 사람과 토론했으며 1 가지 핵심 아이디어에 대해 의견이 맞지 않습니다. 문제는 내가 이야기하는 사람이 단위 테스트가 수행되는 데이터베이스에 미리 채워진 데이터가 있어야한다고 생각하고 테스트가 실행되기 전후에 완전히 비어 있어야한다고 생각합니다.
데이터베이스에서 사전에 채워진 데이터에 대한 나의 관심은 데이터가 양호한 상태로 유지되도록하는 방법이 없다는 것입니다. 테스트 자체는 데이터베이스에서 데이터를 작성, 삭제 및 수정하므로 테스트를 시작하기 전에 데이터베이스에 데이터를 보유하는 것이 좋은지 실제로 알지 못합니다.
데이터베이스 기능을 테스트하는 가장 좋은 방법은 다음 설정을하는 것 같습니다.
- 테스트가 실제로 실행되기 전에 “설정”단계에서 먼저 데이터베이스의 모든 테이블을 자릅니다.
- 그런 다음 실행하려는 테스트 케이스에 필요한 모든 데이터를 삽입하십시오.
- 그런 다음 테스트 사례를 실행하고 검증합니다.
- 그런 다음 “teardown”단계에서 데이터베이스의 모든 테이블을 다시 한 번 자릅니다.
테스트하려는 데이터가 테스트 가능한 좋은 테스트인지 확인하는 다른 더 좋은 방법은 없습니다.
여기에 뭔가 빠졌습니까? 이것이 데이터베이스 관련 기능을 테스트하는 가장 좋은 방법이 아닙니까? 테스트를 시작하기 전이나 테스트를 마친 후에도 데이터베이스에 항상 존재하는 미리 채워진 데이터베이스가 있으면 어떤 이점이 있습니까? 내 요점을 더 잘 이해하기 위해 내 과정을 다르게 설명하는 아이디어에 대한 도움도 훌륭합니다 (즉, 요점에 장점이있는 경우).
답변
나를 위해 단위 테스트는 데이터베이스를 다루지 않아야하며 통합 테스트는 데이터베이스를 다루어야합니다.
데이터베이스를 다루는 통합 테스트는 실제로 데이터베이스를 분리 및 해제하는 비어있는 데이터베이스를 가져야합니다. 트랜잭션 기반 접근 방식을 사용하는 것이 아주 좋은 방법입니다 (즉, 설정시 트랜잭션 작성 및 분리시 롤백).
친구가하고 싶은 것처럼 말하는 것은 ‘회귀’관점에서 테스트하는 것입니다. 즉, 실제 데이터를 가지고 시스템이 어떻게 반응하는지 확인하십시오. 도메인 모델에 몇 가지 단점이 있습니다.
최선의 방법은가는 길이며, 내가하는 경향이있는 것은 잘못된 데이터에 대한 시나리오를 찾은 경우 설정으로 통합 테스트를 작성하고 정확한 시나리오로 분류하는 것입니다.
답변
테스트가 데이터베이스에 의존하는 경우 관심있는 데이터가 데이터베이스가 비어있는 것이 아니라 테스트의 알려진 상태에있는 것이 더 중요하다고 생각합니다. 좋은 테스트 방법 중 하나는 각 테스트가 한 가지 이유로 실패해야하며 같은 이유로 다른 테스트가 실패해서는 안된다는 것입니다.
따라서 테스트에서 데이터 상태에 관심이있는 경우 데이터를 알려진 상태로 가져오고 테스트가 실행 된 후 데이터를 해당 상태로 되 돌리면 테스트를 재현 할 수 있습니다.
조롱하여 데이터 상태에서 테스트를 분리 할 수 있다면 좋은 것입니다. 단위 / 통합 테스트를하고 있다고 언급하지만 물론이 두 가지를 별도로 고려해야합니다. 가능하면 단위 테스트는 데이터베이스에서 분리해야하며 통합 테스트는 데이터베이스를 알려진 상태에서 테스트해야합니다.
답변
글쎄, 나는 미리 채워진 데이터베이스를 가질 때 한 가지 이점을 보았습니다. 필요한 데이터가 있기 때문에 필요한 데이터를 삽입하는 코드를 작성할 필요가 없습니다. 그렇지 않으면 단점 만 있습니다. 어쩌면 누군가 데이터베이스의 테스트 데이터를 수정했을까요? 누군가가 데이터를 새로 고치려고했을까요? 그러나 더 나쁜 것은 하나의 테스트 사례가 데이터베이스를 심하게 망쳐 놓는 것입니다 … 전체 데이터베이스를 수동으로 여러 번 다시 작성하게됩니다.
내가 아무것도 자르지 않을 것 외에는 테스트 작성 방법이 옳습니다.
- 설정 단계 : 데이터베이스에 연결하고 데이터 삽입
- 실행 단계
- 분해 단계 : 삽입 된 데이터 제거 (잘라 내기)
이제이 시나리오는 단위 테스트에 좋습니다. 단위 테스트와 통합 테스트 모두에 대한 데이터가 필요한 경우 모든 테스트 사례에 공통적 인 하나의 큰 설정 단계 (모든 “삽입”을 하나의 정적 방법으로 다시 그룹화)도 매우 효과적 일 수 있음을 발견했습니다. 그것은 당신의 아이디어와 친구의 아이디어 사이의 중간 근거와 같습니다. 유일한 단점은 기존 테스트 사례를 중단하지 않기 위해 새 데이터를 추가 할 때 매우주의해야한다는 것입니다 (그러나 테이블 당 2-3 행을 추가하는 경우 문제가되지 않습니다)
답변
동료와 함께 예제를 좁히고 정확히 무엇을 의미하는지 찾아야한다고 생각합니다. 둘 다 같은 페이지에있을 수 있습니다.
예 : 계정 거래 테이블 확인
- 거래가없는 사용자 / 계정에 대해이 테이블보기를 테스트하고 싶지 않습니까?
- 첫 번째 레코드 추가를 테스트하고 잔액을 만들 수 있는지 확인하십시오.
- 기존 레코드가 이미있을 때 레코드를 작성하고 실행 잔액 및 기타 비즈니스 규칙을 확인하십시오.
- 기존 레코드와 다른 모든 CRUD가있는 테이블을 봅니다.
1 단계와 2 단계를 실행하거나 이미이 상태에있는 데이터베이스 (백업 복원?)로 시작하여이를 수행하는지 여부는 중요하지 않습니다. 나에게 스크립트를 작성한다는 아이디어는 필요한 모든 변경 사항을보다 쉽게 관리 할 수 있도록합니다 (관리자 계정을 만드는 것을 잊어 버린 경우와 마찬가지로 새 사용자에게 필요한 경우). 스크립트 파일은 일부 백업 파일보다 소스 제어에 더 쉽습니다. 또한이 앱을 배포할지 여부에 따라 영향을받습니다.
답변
몇 가지 답변의 측면을 함께 그려 내 2p를 추가하려면 …
참고 : 내 의견은 특히 데이터베이스 테스트 와 관련이 있으며 UI 테스트는 아닙니다 (물론 비슷한 적용).
데이터베이스는 프런트 엔드 애플리케이션만큼 테스트가 필요하지만 ‘프론트 엔드와 작동합니까?’에 기초하여 테스트되는 경향이 있습니다. 또는 ‘보고서가 올바른 결과를 낳습니까?’라고 생각합니다. 이는 데이터베이스 개발 프로세스에서 매우 늦게 테스트되고 있지만 강력하지는 않습니다.
우리는 일반적인 UAT / 성능 / 기타 외에도 데이터웨어 하우스 데이터베이스에 대한 단위 / 통합 / 시스템 테스트를 사용하는 많은 클라이언트를 보유하고 있습니다. 테스트. 그들은 지속적인 통합과 자동 테스트를 통해 전통적인 UAT에 도달하기 전에 많은 문제를 해결함으로써 UAT 시간을 절약하고 UAT 성공 가능성을 높입니다.
데이터베이스 테스트에는 프런트 엔드 또는 보고서 테스트와 비슷한 엄격한 기준을 적용해야한다는 데 동의 할 것입니다.
테스트의 핵심은 복잡한 엔티티 조합으로 진행하기 전에 작은 간단한 엔티티를 테스트하여 정확성을 확인하고 더 넓은 시스템으로 확장하기 전에 정확성을 확인하는 것입니다.
그래서 내 대답에 컨텍스트를 제공합니다 …
단위 테스트
- 테이블, 뷰, 함수, 저장 프로 시저와 같이 장치가 작동 함을 입증하기위한 테스트 중점
- 외부 의존성을 제거하기 위해 인터페이스를 ‘스텁’해야합니다
- 자체 데이터를 제공합니다. 데이터의 알려진 시작 상태가 필요하므로 기존의 사전 테스트 데이터가있을 가능성이있는 경우 채우기 전에 절단 / 삭제가 발생해야합니다.
- 자체 실행 컨텍스트에서 이상적으로 실행됩니다.
- 자체적으로 정리하고 사용한 데이터를 제거합니다. 스텁을 사용하지 않는 경우에만 중요합니다.
이 작업의 장점은 테스트에 대한 모든 외부 종속성을 제거하고 정확성을 입증하기 위해 최소량의 테스트를 수행한다는 것입니다. 분명히 이러한 테스트는 프로덕션 데이터베이스에서 실행할 수 없습니다. 다음을 포함하여 단위 유형에 따라 여러 가지 유형의 테스트가 수행 될 수 있습니다.
- 스키마 검사, 일부는 이것을 ‘데이터 계약’테스트라고 부를 수 있습니다
- 통과하는 열 값
- 함수, 프로 시저, 뷰, 계산 된 열에 대해 서로 다른 데이터 값을 갖는 논리 경로의 운동
- Edge Case Testing-NULL, 잘못된 데이터, 음수, 너무 큰 값
(단위) 통합 테스트
이 SE 게시물이 다양한 유형의 테스트에 대해 도움 이 된다는 것을 알았 습니다 .
- 유닛이 서로 통합됨을 입증하기위한 테스트 초점
- 여러 장치에서 함께 수행
- 외부 의존성을 제거하기 위해 인터페이스를 ‘스텁’해야합니다
- 외부 데이터 영향의 영향을 제거하기 위해 자체 데이터를 제공합니다.
- 자체 실행 컨텍스트에서 이상적으로 실행됩니다.
- 자체적으로 정리되고 생성 된 데이터를 제거합니다. 스텁을 사용하지 않는 경우에만 중요합니다.
단위 테스트에서 이러한 통합 테스트로 이동할 때 더 광범위한 테스트 사례를 테스트하기 위해 데이터가 약간 더 많습니다. 분명히 이러한 테스트는 프로덕션 데이터베이스에서 실행할 수 없습니다.
그런 다음 데이터 양이 증가하고 범위가 증가하는 시스템 테스팅 , 시스템 통합 테스팅 (일명 엔드 엔드 테스팅)으로 진행됩니다. 이러한 모든 테스트는 회귀 테스트 프레임 워크의 일부가되어야합니다. 이러한 테스트 중 일부 는 사용자가 UAT의 일부로 수행하도록 선택할 수 있지만 UAT는 IT에서 정의한 일반적인 문제가 아니라 사용자가 정의한 테스트입니다 !
이제 실제 질문에 대답하기 위해 몇 가지 맥락을 설명 했습니다.
- 단위 및 통합 테스트를위한 데이터를 미리 채우면 가짜 테스트 오류가 발생할 수 있으므로 피해야합니다.
- 일관된 테스트를 보장하는 유일한 방법은 소스 데이터에 대한 가정을하지 않고 엄격하게 제어하는 것입니다.
- 한 테스터가 다른 소스 제어 데이터베이스 코드 분기에서 동일한 테스트를 수행하는 다른 테스터와 충돌하지 않도록하려면 별도의 테스트 실행 컨텍스트가 중요합니다.
답변
솔직히 기존 프로덕션 데이터베이스와 거의 동일한 크기의 데이터베이스없이 단위 테스트를 수행하면 테스트를 통과하고 성능을 위해 프로덕션에 실패하는 많은 것들이 생길 것입니다. 물론 나는 이런 이유로 작은 로컬 데이터베이스를 개발하는 사람들에게 반대합니다.
코드가 데이터에 특정한 경우 데이터없이 어떻게 효과적으로 테스트 할 수 있습니까? 쿼리가 올바른 결과를 반환했는지 확인하지 못할 것입니다. 빈 데이터베이스에 대한 테스트를 고려하고 싶은 이유는 무엇입니까? 쿼리가 정확하지 않고 구문이 올바른지 알려줍니다. 그것은 근시안적입니다. 나는 엄청나게 잘못된 테스트를 실행하고 통과하는 것을 너무 많이 보았다. 단위 테스트에서 그것을 원하지 않습니까? 나는한다.