바닥부터 천천히

스터디/코드리뷰

의존성 역전을 활용하여 테스트하기 쉬운 구조를 만들자

들어가며테스트 코드를 작성하다보면 "이건 어떻게 테스트하지?" 싶은 순간이 온다.대표적으로 랜덤, 시간, 외부 API처럼 개발자가 제어할 수 없는 요소에 의존하는 코드가 그렇다.이런 코드를 테스트하려고 mock 라이브러리를 꺼내드는 경우를 종종 보는데mock 없이도 충분히 테스트할 수 있는 방법이 있다.의존성 역전 원칙(DIP)을 활용하면 된다.mock 을 무분별하게 사용하면 코드에서 악취가 나는 경우가 많다.가능하면 사용하지 말고 적저잭소에만 쓰자문제 상황아래와 같이 슬롯머신 게임을 구현한 객체가 있다고 하자.public class SlotMachine { private static final int REEL_COUNT = 3; private static final int MAX_SYMBOL..

스터디/코드리뷰

테스트를 위해 접근 제어자를 넓히지 말자

들어가며테스트 코드를 작성하다보면 한 번쯤은 이런 유혹에 빠진다."이 메서드를 테스트하고 싶은데 private이라 접근이 안 되네.. public으로 바꿀까?"마음은 이해한다.그런데 테스트를 위해 접근 제어자를 넓히는 순간, 캡슐화가 깨지고 설계가 무너지기 시작한다.테스트하기 어렵다는 것은 접근 제어자의 문제가 아니라 설계의 문제일 확률이 높다.이 부분에 대해 이야기해보자.문제 상황아래와 같이 주문 금액을 계산하는 객체가 있다고 하자.public class Order { private final List items; public Order(List items) { this.items = new ArrayList(items); } public int calculateTot..

스터디/코드리뷰

방어적 복사를 습관화하자

들어가며객체를 설계할 때 가장 중요한 것 중 하나가 신뢰성이지 않을까?신뢰성을 판단하는 지표야 여럿 있겠지만 지금 다루어볼 건 객체가 외부에서 어떻게 사용되든 내부 상태가 안전하게 유지되어야 한다는 것이다.그런데 코드리뷰를 하다보면 이 부분을 놓치는 경우 종종 보곤 한다.특히 컬렉션을 다루는 객체에서 이런 문제가 자주 발생하는데생성자에서 외부 컬렉션을 그대로 받아들이거나, getter에서 내부 컬렉션을 그대로 반환하는 경우이다.이번에는 이러한 문제가 왜 위험한지, 그리고 어떻게 방어할 수 있는지 살펴보자.문제 상황 1 - 생성자에서 외부 컬렉션을 그대로 받는 경우아래와 같이 주문 항목들을 관리하는 일급 컬렉션이 있다고 하자.public class OrderItems { private final Li..

스터디/코드리뷰

값을 감싸서 값 객체로 표현해보자

들어가며원시 값들은 그 자체로 의미가 있긴한다. int는 숫자, String은 문자열 등등..그런데 int와 String을 단순한 숫자와 문자열로 사용하지 않는 경우 불편한 상황이 생긴다. 여기서 불편한 상황이라면 int와 String을 특정한 맥락에서 사용할 때 최소한의 방어장치들이 없다는 것이다.더 나아가 이러한 값들을 활용한 특별한 비즈니스 로직을 표현하기 불편한 상황이 있다. 구체적으로 어떠한 상황이 있을지 살펴보고이러한 문제를 해결하기 위해 값을 감싸서 값 객체로 표현해보도록 하자. 예시문자열로 식을 입력받아 계산을 하고 다음과 같은 제약 조건이 있다고 가정하자. 정책문자열로 식을 전달받는다.식의 구성은 숫자와 연산자로 이루어져 있으며 연산자는 덧셈, 뺄셈, 나눗셈, 곱셈만 지원한다.연산 순서는..

스터디/코드리뷰

테스트 코드에는 일련의 로직을 넣지 말자

들어가며테스트 코드의 미덕은 무엇일까~프로덕션 코드의 안정성을 비롯해 여러가지 장점이 있겠지만프로덕션 코드가 어떻게 동작하는지 설명하는 문서로써의 역할도 톡톡히 한다고 볼 수 있다. 다시말해 누군가가 읽어야 하는 대상이라는 말이다.누군가가 읽어야 한다면 읽는데 부담이 없어야 하니 이해를 방해하는 요소는 적으면 적을수록 좋다.그런데 테스트 코드를 작성하다보면 유혹에 넘어가 이해를 방해하는 요소를 작성하는 경우가 생기곤 한다. 물론 코드를 작성하는 당시 '나'는 해당 코드를 잘 이해할수 있을지 모르지만한달이 지나고 두달이 지난뒤 그 코드를 다시 읽는 '나'는 이전의 '나'와 거의 다른사람이다.결국 내가 작성한 코드도 쉽게 이해하지 못 할 수 있다. 여기서 이해를 방해하는 요소는 테스트 코드에 일련의 로직을 ..

스터디/코드리뷰

하드코딩한 매직넘버는 상수로써 표현하자

들어가며코드리뷰 사항 중 꽤 개선하기 쉬운 부분이다.그런데 생각보다 잘 지켜지지 않는 부분인것 같기도 하다. 프로그래밍에서 상수(static final)로 선언하지 않은 숫자를 매직 넘버, 문자열을 매직 리터럴이라 한다.이를 정적(static)이고 변경 불가능(final)한 상수로 선언하여 사용하자. 간혹 단순히 값을 옮겨적는것이 상수로 표현한다고 착각하는 경우도 있는 것 같다.해피케이스와 배드케이스로 나누어 살펴보도록 하자 문제상황예전에 대학생때 다른 블로그에 써둔 주제가 동일해서 그대로 가져왔다. AS-ISpublic class Noise { private final double decibel; public Noise(double decibel) { validate(decibe..

스터디/코드리뷰

테스트도 단일책임원칙을 지키자

들어가며테스트 코드를 작성하는게 익숙치 않은 리뷰이들을 보면 간혹 테스트에서 여러가지를 한번에 테스트하는 모습을 보곤한다.여러가지라 표현한 이유는 그 케이스가 하나의 양상을 띄는게 아니라서 그렇다. 동일한 케이스에 대한 반복을 하는 경우도 있고해피케이스와 엣지케이스를 섞기도 하며컨텍스트를 유지하며 일련의 흐름을 작성하기도 한다. SRP(Single Responsibility Principle: 단일책임원칙)에 대해 한번쯤 들어봤으리라 생각한다.어떠한 객체에게 하나의 책임만 있어야 한다고 하는데 사실은 단일 (변경)책임 원칙이다.위키피디아를 보면 다음과 같이 적혀있다.The single-responsibility principle (SRP) is a computer programming principle ..

스터디/코드리뷰

생성자 내부에서 너무 많은 일을 하지 말자

들어가며나도 예전에 생성자 내부에서 이리저리 지지고 볶다보니 문제를 겪은 적이 많다.단적인 예로 외부 통신하는 RestTemplate을 wrapping하는 클래스를 만들었었는데생성자 내부에서 RestTemplate을 만들다 보니 테스트하기가 너무 힘든 구조가 됐었다. 이때 피부로 느끼고 깨달음을 얻었던 부분이 멤버변수를 생성하기 위한 로직을 생성자 내부에서 만들지 말자는 것이다.생성자에서 뭔가 멤버변수를 생성하는 로직이 너무 많으면 이를 제어하고 테스트하기 너무 힘들어진다.멤버변수 생성에 대한 로직이 필요하다면 별도의 Factory를 두는것이 더 적절하다고 본다. 그리고 부가적인 이점이 있는게 리팩터링 내성이 올라간다.리팩터링 내성이라 함은 작성해둔 테스트 코드가 운영코드의 리팩터링이 발생했음에도 컴파일..

스터디/코드리뷰

Exception을 테스트 할 때 거짓 음성을 주의하자

거짓 음성여기서 언급한 거짓 음성이 무엇인지 먼저 짚고 넘어가자~거짓 음성이란 실제로는 실패해야 하는 테스트가 통과하는 경우를 의미한다.다시말해 기능이 고장났는데 테스트가 통과하는 케이스를 의미한다. 보통 테스트의 정확도를 이야기할 때 거짓 음성과 거짓 양성에 대해 이야기를 한다.대게 거짓 양성에 대해 더 중요하게 다루곤 하지만 코드리뷰를 하며 거짓 음성을 발생시키는 케이스를 많이 본 것 같다. 조금 더 정확히 짚고 넘어가면 기능이 실패한다기 보다 기능에 대해 테스트가 정확히 검증해주지 못하는 케이스라고 봐야할 것 같다. 예제 코드 1그래서 Exception을 테스트하는 것과 어떤 관련이 있는가 싶을텐데코드로 살펴보도록 하자~public class MyCollection { private stati..

스터디/코드리뷰

코드 리뷰 요청에 정성을 담아보자

습관의 중요성나도 잘 못하기는 하는데 그래도 아무것도 안적는 사람들이 생각보다 많아서 적는다.말 그대로 코드리뷰 요청을 보내는데 코드리뷰 본문에 아무것도 적지 않는 사람들이 종종 있다. 이렇게 본문이 텅~ 비어버린 코드리뷰를 보면 어떤 생각이 들까?진짜 어렵다.뭘 해줘야 하는지 길을 찾기가 너무 어렵다.이렇게 되면 코드 컨벤션에 대해서만 주구장창 잡기도 한다. 내가 지금 재직중인 회사에는 아래와 같은 말이 있다.코드리뷰도 정~~~~말 똑같다고 느낀다.코드리뷰를 요청한, 만든사람이 본문에 내용을 잘 담아주면 코드 리뷰어가 방향성을 잡고 리뷰를 해주기 참~ 좋다. 나중에 취업하고 본격적으로 일할 때도 굉장히 중요한 요소이다.내가 PR을 생성해서 코드리뷰를 요청했는데 본문이 텅 비어있으면팀원들은 뭘 리뷰해줘..