JUnit16 4. 테스트하기 좋은 코드 - 검증이 필요한 비공개 함수 지난 시간까지 테스트하기 어려운 코드를 어떻게 개선하면 좋을지에 대해 이야기를 나눴다. 1. 테스트하기 어려운 코드 2. 제어할 수 없는 코드 개선 3. 외부에 의존하는 코드 개선 지금까지 글들의 결론은 간단하다. 테스트 하기 어려운 코드와 테스트 하기 쉬운 코드를 분리하되, 테스트 하기 어려운 코드는 최대한 바깥으로 몰아넣는다. 전체적인 방향성은 위와 같이 유지하되, 이번에는 조금 더 세밀한 내용을 보자. 비즈니스 로직을 작성하다보면 무수히 많은 private 메소드/함수들을 생성하게 된다. 이전 글에서도 언급했지만, private 메소드/함수의 테스트 코드는 작성하지 않는 것이 좋을때가 많다. 테스트 코드에서 내부 구현 검증 피하기 그럼에도 불구하고 private 메소드/함수를 검증해야할 경우가 있다.. 2022. 10. 2. 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. 단언문 (expect/assert) 안에서 비교하지 않기 간혹 코드를 보면 expect 에서 비교를 하는 코드를 보곤 한다. 이를테면 다음과 같은 경우이다. it('getCount의 결과는 5보다 크다', () => { const result = getCount(); expect(result > 5).toBe(true); }); 당장 봐서는 문제가 없어보인다. 오히려 비교값이 더 큰지 검증하는 jest 함수를 별도로 찾아보지 않아도 된다는 장점도 있어보인다. 비슷한 예제로 다음과 같은 코드도 종종 보게 된다. it('getCount의 값은 10과 동일하다', () => { const count = getCount(); expect(count === 10).toBe(true); }); 하지만 이 테스트 코드들은 크게 2개의 단점을 갖고 있다. (정확히는 잘못된 .. 2022. 4. 10. 조건부 (if~else) 로직 테스트코드에서 사용하지 않기 테스트 코드는 프로젝트의 생명 주기 보다 길때가 많다. 기존의 요구사항을 정리한것이 테스트 코드이기 때문에, 메인 코드보다 훨씬 더 읽기쉬워야만 한다. 만약 테스트 코드가 복잡한 경우 어떻게 작동하는지 이해하기가 어렵다. 그래서 테스트 코드는 주석이 필요 없을 정도로 간단해야 한다. 그런면에서 조건부 (if ~ else) 테스트 로직은 테스트를 실제보다 더 복잡하게 만드는 요인 중 하나다. 이번 글에서는 조건부 로직을 테스트에서 사용한 경우에 어떻게 개선할 수 있을지 알아본다. 1. 가변 결과를 검증하는 경우 1-1. 문제 첫번째 문제는 다음과 같이 테스트 실행때마다 결과가 달라지는 경우이다. it('[Bad] 가변결과 검증', () => { const now = LocalDateTime.now(); c.. 2022. 3. 7. 이전 1 2 3 다음
