직장에서 내 프로젝트 중 하나는 주로 외부 클라이언트에서 전달 된 데이터를 가져 와서 데이터베이스에 유지하는 것입니다. JPA를 사용하는 Java 엔터프라이즈 응용 프로그램이며 대부분의 논리는 CRUD 작업을 중심으로 이루어집니다.
대부분의 버그는 JPA와 관련이 있습니다.
- 예 1 : 저장 단추를 두 번 클릭하면 JPA가 동일한 엔티티를 데이터베이스에 두 번 삽입하려고 시도하여 기본 키 위반이 발생할 수 있습니다.
- 예 2 : 데이터베이스에서 엔티티를 검색하여 편집 한 후 데이터를 업데이트하려고합니다. JPA는 기존 인스턴스를 업데이트하는 대신 새 인스턴스를 만들려고 시도 할 수 있습니다.
종종 솔루션에서 JPA 주석을 추가 / 제거 / 변경해야합니다. 다른 경우에는 DAO 로직 수정과 관련이 있습니다.
단위 테스트와 TDD를 사용하여 코드에 자신감을 얻는 방법을 알 수 없습니다. 단위 테스트와 TDD가 적합하지 않거나 문제에 잘못 접근했는지 확실하지 않습니다.
단위 테스트는 런타임에만 이러한 문제를 발견 할 수 있고 문제를 재현하기 위해 앱 서버에 배포해야하기 때문에 적합하지 않은 것 같습니다. 일반적으로 단위 테스트의 정의를 벗어난 것으로 간주되는 데이터베이스가 필요합니다. 통합 테스트입니다.
배포 + 테스트 피드백 루프가 너무 느려서 비생산적이기 때문에 TDD가 적합하지 않은 것 같습니다. 배포 + 테스트 피드백 루프는 3 분 이상 소요되며, 내가 작성하는 코드에 대해 테스트를 실행하면됩니다. 모든 통합 테스트를 실행하려면 30 분 이상이 걸립니다.
이 금형 외부에 코드가 있으며 가능할 때마다 항상 단위 테스트를 수행합니다. 그러나 대부분의 버그와 가장 큰 시간 싱크에는 항상 JPA 또는 데이터베이스가 포함됩니다.
비슷한 또 다른 질문이 있지만 조언을 따르면 내 코드 (JPA)의 가장 불안정한 부분을 감싸고 모든 것을 테스트합니다. 내 질문의 맥락에서, 나는 같은 나쁜 상황에 처했을 것입니다. JPA를 포장 한 후 다음 단계는 무엇입니까? 그 질문에 대한 IMO는 아마도 내 질문에 대답하기위한 단계 일 것입니다.
unit testing != TDD)