오늘은 무슨 일이?
추상화, Mocking
오늘 호눅스 수업에서는 Random 을 테스트 하는법에 대해 배웠습니다.
Random 처럼 결과를 예측할 수 없는 모듈을 사용하는 로직을 테스트하기 위해서 여러가지 시행착오를 일부러 보여주셨는데요.
Random 을 사용한 메소드를 테스트 하려고 보니, 여러번 테스트 해보는 방법 밖에는 없었습니다.
그래서 10번 100번 10000번 테스트를 해도 그 결과가 영 찝찝했습니다.
다른 방법을 찾으며 마지막에 알게된 방법은, 추상화와 가짜 객체(Mock Object)를 이용하는 것 이었습니다.
예측할 수 없는 모듈을 인터페이스로 추상화 하고, 해당 로직에서는 Random 대신 인터페이스를 참조하여 사용합니다.
그리고 해당 클래스에서 생성자에서 인터페이스의 구현체를 주입받도록 변경하면, 외부에서 유연하게 구현체를 변경할 수 있습니다.
이렇게 추상화와 다형성으로 유연하게 구현체를 변경할 수 있게 되면, Mock Object를 구현체로서 주입할 수 있게되는데요.
구현체를 유연하게 변경할 수 있게 되면, 예측 불가능한 모듈을 예측 가능한 가짜 객체(Mock Object)로 바꿔치기 할 수 있습니다.
그리고 예측 가능한 객체를 사용하게 되면, 신뢰할 수 있는 테스트 코드를 작성할 수 있게 되죠.
그러면 더 이상 우리는 찝찝한 테스트 코드가 아닌, 신뢰할 수 있는 테스트 코드를 통해 자신감을 얻을 수 있게 됩니다.
그러면 'Random 하지 않은 객체를 사용하지 않으면 테스트가 의미없는거 아닌가?' 라고 생각할 수도 있습니다.
하지만 결과를 예측할 수 없는 모듈을 사용하는 로직을 테스트하는건, 예측할 수 없는 환경에서 정성상적으로 동작하는지가 아닙니다.
우리가 확인해야할 가장 중요한 사항은 객체들이 올바르게 협력하고 있는지를 확인하는 것 입니다.
그래서 Random 한지 아닌지의 여부 보다는, 특정 값이 주어졌을때 우리가 의도한 대로 동작하는지를 확인하면 되는것 입니다.
정리하면, 우리는 예측할 수 없는 모듈을 추상화 하여 메인 로직과 서로 약한 참조 관계를 맺도록 만들고,
이 약한 참조관계를 이용하여 가짜 객체를 대신 주입하여, 예측할 수 있는 테스트를 만들 수 있다는 것 입니다.
그리고 위 내용은 Random 뿐만 아니라, HTTP 요청 처리, 외부 API 등등 결과를 예측할 수 없는 모듈뿐만이 아니라,
오버헤드가 크거나, 여러번 실행하기 어려운 모듈에도 적용될 수 있다고 합니다.
추천링크
페어 리펙토링..!
오늘은 donggi와 오후시간 내내 리펙토링을 진행했습니다.
객체의 역할과 책임을 고려한 리펙토링을 하다보니, 상대적으로 경험이 조금 더 많은 제가 계속 주도하게 되었는데요.
제가 '이렇게 해야할 것 같다' 라고 주장을 먼저 계속 말하면 이건 협력 요청이 아니라, 협조 요청이 될 것 같았습니다.
그래서 내가 생각한 방법을 바로 주장하기 보다는, 질문을 먼저 많이 하려고 했습니다.
그러면 동기는 잠시 생각하는 시간을 가지신 뒤 생각하신 방법을 조심스레 말씀해주셨습니다.
몇일 진행하는 동안 서로에 대한 경험치가 쌓인건지, 제가 생각했던것과 같은 방법을 많이 제시해 주셔서 재미있었습니다.😊
그렇게 불분명한 클래스 이름, 여러가지 역할을 가진 객체, 하나의 객체로 만들 수 있는 변수들 등등을 고쳐나갔는데요.
하나씩 고쳐나가다 보니 오늘 정해진 시간이 다 되어, 내일을 기약하고 페어프로그래밍을 종료하였습니다.
내일은 donggi와의 이번주 마지막 페어프로그래밍(😢)에서는 남은 로직을을 마저 리펙토링 하기로 했습니다.
인프런 라이브
오늘 9시에는 인프런에서 10만 수강자를 달성하신 배민 기술이사 김영한님의 Q&A 및 인프런 실버 버튼(?) 증정식이 있었습니다.
많은 질문들이 오갔지만, 그 중에서 가장 인상깊었던 내용은 다음과 같습니다.
- 목표 보다는 시스템을 만들어라
- 입사해서 일을 잘하려먼, 모든 업무 도메인을 파악해라!
- 테이블 및 테이블의 필드들
- 도메인 및 도메인의 필드들
- 개발 지식을 '아는것'에서 그치면 안되고,
체화→정리까지 해야한다- Java ex) 멀티 스레드
- HTTP ex) POST 와 PUT의 차이 등
- DB
- 스프링
- JPA ex) n+1 문제 등
모든 내용이 좋았지만, 이 중에서 제일 와닿았던 내용은 목표 보다는 시스템을 만들어라였습니다.
이때까지는 나 스스로가 더 나은 방향으로 가고싶을때, 내가 달성해야할 목표를 정하고 이를 달성하기 위해 기한을 정했습니다.
하지만 성공했던 적은 거의 없었는데, 예상치 못한 변수가 생기거나 과도한 목표에 압도되어 의욕을 잃은 경우가 대다수 였습니다.
그렇지만 추상적으로 목표만 잡아놓고, 매일 아주 작은 단위의 목표를 달성하는 시스템을 만들면 성공하기 쉽다고 합니다.
예를 들어 '오늘은 책 한장만 읽어야지' 같은 목표를 정한다면, 가벼운 마음으로 책을 피게되고, 책을 피면 1장이 아니라
2장 3장을 읽을 가능성이 높아지는데요.
결국 목표 보다 중요한 것은 실천이며, 실천을 쉽게 하기위해서 작은 목표를 잡아야 합니다.
그리고 제일 중요한 것은 이를 꾸준히 실천하는 것 입니다.
꾸준히 실천하는것이 바로 시스템이고 이 시스템을 잘 유지보수하며 오래 동작하도록 하다보면, 어느새 목표를 달성하였을 것 입니다.
인상깊었던 점은?
- 추상화와 Mocking을 설명하기 위한 호눅스의 빌드업
donggi와 여러번 생각이 통해서 재밌었던 경험- 목표 보다는 시스템
- 루테인 다시 먹으니까 눈이 안따가움..(루테인 효과 좋네)
아쉬웠던 것은?
- 오늘따라 회고에 쓰고싶은 내용이 많아서, 늦게 자버렸네요.