본문 바로가기
반응형

testable code4

5. 테스트하기 좋은 코드 - SQL 지난 시간까지 애플리케이션 코드를 어떻게 개선하면 좋을지에 대해 이야기를 나눴다. 1. 테스트하기 어려운 코드 2. 제어할 수 없는 코드 개선 3. 외부에 의존하는 코드 개선 4. 검증이 필요한 비공개 함수 개선 이번 편에서는 애플리케이션 코드가 아닌 Query (비단 RDBMS뿐만 아니라 NoSQL도 해당) 에 대해서 이야기를 해본다. 최근엔 ORM (혹은 ODM) 사용이 대중화되었지만, 여전히 많은 프로젝트에서는 SQL Builder를 통해서 Native Query를 작성한다. SQL Builder를 통해서 Native Query를 작성하는 것은 복잡한 조회 조건이 필요한 환경에서는 굉장히 효율적인 방법이다. 예를 들어, 통계/정산/물류 등 복잡한 조회 Query가 필요하거나, Bulk Insert등.. 2022. 10. 18.
3. 테스트하기 좋은 코드 - 외부에 의존하는 코드 개선 지난 시간에 테스트하기 좋은 코드에 대해 이야기를 나눴다. 1. 테스트하기 어려운 코드 2. 제어할 수 없는 코드 개선 이번 편에서는 테스트하기 어려운 코드를 개선하는 2번째 방법인 외부에 의존하는 코드를 개선하는 방법에 대해 이야기를 해보자. 3-1. 문제 상황 1부 에서 소개했던 cancel() 코드를 다시 보자. export default class Order { ... async cancel(cancelTime): void { if(this._orderDateTime >= cancelTime) { throw new Error('주문 시간이 주문 취소 시간보다 늦을 수 없습니다.'); } const cancelOrder = new Order(); cancelOrder._amount = this._a.. 2022. 9. 27.
2. 테스트하기 좋은 코드 - 제어할 수 없는 코드 개선 1편 을 통해 테스트하기 어려운 코드에 대해 이야기를 나눴다. 이번 편에서는 테스트하기 어려운 코드 중 첫번째인 "제어할 수 없는 코드를 개선하는 법"을 이야기해보자. 2-1. 문제 상황 먼저 앞에서 보았던 discount() 코드를 다시 보자. export default class Order { ... discount() { const now = LocalDateTime.now(); if (now.dayOfWeek() == DayOfWeek.SUNDAY) { this._amount = this._amount * 0.9 } } } 이 discount() 는 실행할때마다 항상 결과가 다르다. LocalDateTimw.now()의 코드를 보면 알겠지만, 현재 시간은 항상 다르기 때문이다. 그렇기 때문에 실행.. 2022. 9. 1.
1. 테스트하기 좋은 코드 - 테스트하기 어려운 코드 팀 분들과 함께 NextStep - 이펙티브 코틀린 강좌를 수강하고 있다. 최근에 과제 회고를 처음 진행했는데, 이때 나온 주제가 테스트 하기 좋은 코드였다. 이 주제는 사실 이미 너무 많이 회자된 주제이긴하다. 대표적으로 아래 2개가 가장 대표적이다. 정진욱님 - Testing, Oh my! 권용근님 - 무엇을 테스트할 것인가 이들을 다 보았다면, 굳이 이 글을 볼 필요는 없다. 이미 잘 정리된 글과 영상이지만, 현재 팀의 분들을 위해서 조금 정리하게 되었다. 뒤에 이어 쓸 Active Record vs Data Mapper의 빌드업이기도 하다. 이 글에서는 테스트하기 어려운 코드 대해 이야기해보려고 한다. 1. 테스트 하기 좋은 코드? 여기서 이야기하는 테스트는 단위 테스트를 의미한다. E2E 테스트.. 2022. 6. 11.

728x90
반응형