단위 테스트와 TDD를 사용하여 주로 데이터베이스 CRUD 작업에 의존하는 앱을 테스트하려면 어떻게해야합니까?


22

직장에서 내 프로젝트 중 하나는 주로 외부 클라이언트에서 전달 된 데이터를 가져 와서 데이터베이스에 유지하는 것입니다. JPA를 사용하는 Java 엔터프라이즈 응용 프로그램이며 대부분의 논리는 CRUD 작업을 중심으로 이루어집니다.

대부분의 버그는 JPA와 관련이 있습니다.

  • 예 1 : 저장 단추를 두 번 클릭하면 JPA가 동일한 엔티티를 데이터베이스에 두 번 삽입하려고 시도하여 기본 키 위반이 발생할 수 있습니다.
  • 예 2 : 데이터베이스에서 엔티티를 검색하여 편집 한 후 데이터를 업데이트하려고합니다. JPA는 기존 인스턴스를 업데이트하는 대신 새 인스턴스를 만들려고 시도 할 수 있습니다.

종종 솔루션에서 JPA 주석을 추가 / 제거 / 변경해야합니다. 다른 경우에는 DAO 로직 수정과 관련이 있습니다.

단위 테스트와 TDD를 사용하여 코드에 자신감을 얻는 방법을 알 수 없습니다. 단위 테스트와 TDD가 적합하지 않거나 문제에 잘못 접근했는지 확실하지 않습니다.

단위 테스트는 런타임에만 이러한 문제를 발견 할 수 있고 문제를 재현하기 위해 앱 서버에 배포해야하기 때문에 적합하지 않은 것 같습니다. 일반적으로 단위 테스트의 정의를 벗어난 것으로 간주되는 데이터베이스가 필요합니다. 통합 테스트입니다.

배포 + 테스트 피드백 루프가 너무 느려서 비생산적이기 때문에 TDD가 적합하지 않은 것 같습니다. 배포 + 테스트 피드백 루프는 3 분 이상 소요되며, 내가 작성하는 코드에 대해 테스트를 실행하면됩니다. 모든 통합 테스트를 실행하려면 30 분 이상이 걸립니다.

이 금형 외부에 코드가 있으며 가능할 때마다 항상 단위 테스트를 수행합니다. 그러나 대부분의 버그와 가장 큰 시간 싱크에는 항상 JPA 또는 데이터베이스가 포함됩니다.


비슷한 또 다른 질문이 있지만 조언을 따르면 내 코드 (JPA)의 가장 불안정한 부분을 감싸고 모든 것을 테스트합니다. 내 질문의 맥락에서, 나는 같은 나쁜 상황에 처했을 것입니다. JPA를 포장 한 후 다음 단계는 무엇입니까? 그 질문에 대한 IMO는 아마도 내 질문에 대답하기위한 단계 일 것입니다.


4
실제로 테스트하기 위해 데이터베이스를 설정해야하므로 기본적으로 통합 테스트입니다. 하나의 모듈이 다른 모듈에 의존한다고 생각할 수 있으므로 통합 테스트와 비슷합니다. TDD 접근 방식을 응용 프로그램에 적용하는 방법에 대한 질문을 변경합니다.
정보 :

@random 정확하게, 나는 그것을 분명히 말하기 위해 내 질문을 편집했습니다. 질문을 변경 한 이유를 모르겠습니다. 정교하게 할 수 있습니까? 나는 것 때문에 거기에서 단위 테스트 부분을 유지하려면 오히려 통합 테스트에 비해 단위 테스트를 작성한다 (나는 알고 있어요하지만 그 unit testing != TDD)
다니엘 카플란

특별한 것은 없지만 TDD를 넣으십시오. 만약 당신이 거기에서 단위 테스트를한다면, 많은 사람들이 당신이 이해하지 못하는 것 등을 생각하지 않을 것입니다 ..
InformedA


답변:


7

한 가지 옵션은 H2 와 같은 메모리 내 테스트 데이터베이스를 사용하는 것입니다 . 표준 디스크 사용 데이터베이스보다 약 10 배 빠르며 시작 / 종료 시간이 짧습니다.

이것이 도움이 될지 여부는 JPA 문제가 다른 데이터베이스에서 여전히 실패 할 정도로 일반적인지 여부에 크게 좌우됩니다. 많은 문제를 놓치면 테스트 실행 속도가 빠르지 않습니다.

그러나 전체 시스템이있는 모든 사람에 대해 H2로 10 회 실행을 수행 할 수 있다면 비용을 지불 할 수 있습니다.


좋은 생각이지만 여전히 앱 서버 AFAIK에 배포해야합니다. 3 분 이상이 걸렸습니다. 그것은 분명히 가치가 있다고 말했습니다. 그러나 단위 테스트를 실행할 때마다 테스트를 실행하는 것은 여전히 ​​어렵 기 때문에 TDD를 사용하여 개발하는 것은 비효율적입니다.
Daniel Kaplan

1
나는 일반적으로 그 요구 사항 주위에 방법이 있다고 생각합니다 (예 : docs.oracle.com/middleware/1212/toplink/TLADG/testingjpa.htm ). 그러나 정당한 것보다 더 많은 일을 할 가능성이 매우 높다. 또 다른 옵션은 더 강력한 테스트 서버를 가져 와서 병렬로 실행하는 것입니다.
soru

1
@tieTYT hsqldb 단위가 github에서 crud 웹 응용 프로그램을 테스트하는 자체 개념 증명 : TestingWithHsqldb- 단위 테스트에는 응용 프로그램을 배포 할 필요가 없습니다.

3

데이터베이스는 단위 테스트가 매우 쉬울 수 있습니다. 저장 프로 시저와 트랜잭션이 필요합니다.

이것이 Microsoft가 데이터베이스 단위 테스트 에 대해 말한 것 입니다. 또한 DB 연결을 설정하고, 트랜잭션을 시작하고, 테스트에 사용할 데이터를 DB에 쓰고 테스트를 실행 한 다음 롤백하여 데이터베이스에 대해 단위 테스트를 실행하고 Java 또는 C #으로 테스트를 작성합니다. 배포 한 DB를 사용하고 있고 완전히 격리 된 테스트를 받으면 DB가 손상되지 않습니다.

이것이 프레임 워크 내에서 수행하는 방법에 대한 통찰력을 줄 수 있기를 바랍니다.


내가 말했듯이 "우리 버그의 대부분은 JPA와 관련이 있습니다."라고 기사의 조언이 그 모든 것을 놓칠 것이라고 생각합니다. 또한 Java / C # 테스트가 여전히 단위 테스트라고 생각하면 정의가 매우 다릅니다. 나는 이것이 일반적으로 좋은 조언이라고 생각하지만 스위트를 배포하고 실행하는 데 많은 시간이 걸리므로 TDD에 도움이되지 않는 것 같습니다. 당신은 동의하지 않습니까?
Daniel Kaplan

우리는 SQL에 대해 DB 단위 테스트를 실행했지만 모두 sprocs에있었습니다. 다른 sql 프로 시저에서 sql 디렉토리를 단위 테스트 할 수는 있지만 단위 테스트 프레임 워크는 MSTest 였으므로 거기에서 실행하는 것이 합리적이었습니다 (빌드 서버에서 녹색 틱 가장 중요했습니다). DB가 항상 설치되어 있고 어쨌든 우리는 int. 테스트를 수행했다면 모든 SQL 코드를 쉽게 업로드하고 빌드 서버에서 모든 단위 테스트를 실행하는 것이 쉽습니다. 때로는 이러한 것들에 대해 실용적이어야합니다.
gbjbaanb

나는 당신이 내 첫 번째 문장에 응답했다고 생각하지 않습니다.
Daniel Kaplan

그럼 jpa-unit을 사용하십시오. JPA 코드가 어떻게 작동하는지 (또는 그렇지 않은지) 대답 할 수 없으며 db에서 해당 SQL을 테스트하는 방법에 대한 아이디어를 제공하려고합니다.
gbjbaanb

3

다른 사람들은 "DB를 모의!" 그러나 실제로 코드와의 상호 작용 방식을 테스트해야하는 경우 DB 레이어를 조롱하는 데있어 요점은 무엇입니까?

당신이 찾고있는 것은 통합 테스트 및 / 또는 자동화 된 UI 테스트입니다. 다음과 같은 경우에 문제가 발생한다고 언급했습니다.

*If you click the save button twice*

이를 테스트하는 유일한 방법은 자동 UI 테스트를 작성하여 단추를 두 번 클릭하는 것입니다. 아마도 셀레늄을 확인하십시오.

아마도 단위 테스트 DB가 필요할 것이고 테스트를 위해 그것을 향할 것입니다. 현실 세계에서 TDD를 유지하기는 쉽지만 환영합니다.


이것은 답변보다 맹목적으로 읽습니다
gnat

통합 테스트, GUI 테스트 및 / 또는 단위 테스트 DB라는 세 가지 질문에 답했습니다. 예, 그것은 약간의 분노입니다, 나는 지금 정신의 일부처럼 편집 할 것입니다.
Rocklan

1
"이를 테스트하는 유일한 방법은 자동 UI 테스트를 작성하여 버튼을 두 번 클릭하는 것입니다. 아마도 Selenium을 확인하십시오." 그러한 상황에서는 백엔드가이를 방지하는 것이 좋습니다. 그렇지 않으면 UI가 데이터베이스에 직접 액세스합니다.
다니엘 카플란

0

귀하의 질문에 제시 한 예에서, 버튼을 두 번 클릭하는 상황으로 유닛 테스트 / TDD를 수행하여 오류를 매우 쉽게 일으킬 수는 없습니다. 그러나 단위 테스트 할 수있는 것은 버튼을 클릭 할 때 호출되는 코드에서 지속성 계층에서 예외가 발생하면 지속성 계층을 조롱하거나 메모리 내 데이터베이스를 사용하여 적절하게 처리한다는 것입니다 다른 답변에서 제안되었습니다)-오류를 던지거나 표시하거나 기타로 표시합니다.

단위 테스트 (예 : 통합 / 시스템 테스트)에 적합하지 않은 테스트를 수행해야 할 때 TDD가 분해되기 시작할 수 있습니다. 이는 최근 "TDD입니까? 죽은?" 켄트 벡, 마틴 파울러, 데이비드 하이네 마이어 핸슨의 토론 : http://martinfowler.com/articles/is-tdd-dead/

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