개발자
저희 팀이 테스트 코드를 개선하고 있는데. 예전에 e2e 위주로 코드를 짰다가 나중에 일정이 밀리고 하면서 코드 유지보수가 안되더군요..ㅎㅎ; 해서 다시 짜는 중인데. 단위테스트로 코드를 짜보려고 하니, db 쿼리 검증이 고민입니다. 저희 팀은 현재는 raw query를 직접 짜서 프로그램을 작성합니다. dba는 따로 없구요.. 원칙적으로는 db 쿼리 결과값을 스텁 처리 하는게 맞고 그 취지는 이해가 가는데. 코드 로직에서 쿼리가 상당히 중요한 부분을 차지하고, 쿼리를 사람이 짜다보니 오류가 발생할 소지가 있습니다. 그래서 테스트 시 검사를 같이 하고 싶긴 한데요.. 추후에는 orm 전환을 고려하고 있지만 현재 일정상으로 당장 진행하기 어려워, 우선은 현재 기준으로 뭔가 쿼리를 검증하면 좋겠는데.. 방법이 뭐가 있을까요..? 좋은 의견이나 혹시 팀에서 이미 비슷한 고민을 해결하신 분이 계시면 의견을 듣고 싶습니다
커리어리 AI 봇
GPT가 달아주는 답변입니다.
2024년 04월 23일
현재 상황에 대한 이해를 바탕으로, 다음과 같은 몇 가지 접근 방식을 제안드립니다: 1. **Mocking DB Responses:** 실제 데이터베이스에 쿼리하지 않고, 테스트 환경에서는 가짜(DB Mock)를 이용하여 DB 응답을 모방(Mocking)합니다. 이렇게 하면 코드의 해당 부분이 예상대로 동작하는지 확인할 수 있습니다. 2. **In-Memory Databases:** 인메모리 데이터베이스(ex: SQLite, H2 등)를 사용하여 실제 쿼리를 테스트 합니다. 인메모리 데이터베이스는 빠르며 각 테스트가 실행될 때마다 초기화됩니다. 3. **Dockerized Databases for Integration Testing:** Docker 컨테이너 내에서 실제 데이터베이스를 실행하고 그것에 대해 직접적으로 통합 테스트를 수행하는 것도 좋습니다. 이 방식은 어플리케이션의 종속성을 관리하고 일관된 테스트 환경을 제공하는 면에서 매우 유용합니다. 4. **SQL Query Validator Libraries/Tools:** SQL 쿼리 유효성 검사 도구 및 라이브러리들(ex: SQLCheck, T-SQL Lint 등)를 사용하여 쿼리 자체가 제대로 작성되었는지 확인할 수 있습니다. 5. **Using a Test Db with same Schema:** 만약 민감한 데이터에 대해 테스트를 해야 한다면, 실제 생산 데이터베이스와 동일한 스키마를 가진 테스트 데이터베이스를 사용하여 쿼리의 정확성을 검증할 수 있습니다. 프로젝트의 요구사항 및 리소스에 따라 다른 접근 방식이 필요합니다. 고려해야 할 주요 요소는 테스트의 격리성, 실행 속도, 코드 복잡성 등입니다.
지금 가입하면 모든 질문의 답변을 볼 수 있어요!