나는 개인적으로 개발할 때,
테스트가 제대로 안되는 상황이 가장 답답하다.
어떤식으로 작동하고 어디서 버그가 발생하는지 정확히 눈으로 보이지 않는 상황이 개발할 때 가장 답답한 것 같다.
대용량 분산 처리. 캐쉬. Message Queue. 마이크로 아키텍처. Redis. NoSQL.
SNS(트위터.라인.페이스북.인스타그램 등) 아키텍처를 공부하면서 연신 감탄하고. 시간복잡도. 공간복잡도를 분석하고. 보다 나은 알고리즘에 대해 생각하고.. 연구하고.. 정말 재밌고 좋다..
다 좋은데,
실상 회사에서 일할때.
가장 많이 접하는 건 거대한 소스덩어리 이고
가장 많이 체감하는 건 이 거대한 소스덩어리 는 정말 많은 객체들과 강력하게 결합돼있고,
단위 테스트를 도무지 어떻게 해야할지 감이 안잡히는 상황 이다.
거대한 소스덩어리는 100% 설계가 잘못된 것이다.
이러한 거대한 소스덩어리는 반드시 버그가 반드시 발생하게 돼있기 때문에 테스트를 잘 해야하는데 쉽지않다.
테스트를 잘 하려면 일단 리팩토링을 하는것이 좋다.
리팩토링은 일단
1. 메소드를 여러개로 쪼개기..
메소드를 여러개로 쪼개다 보면 어떤 메소드에는 너무 많은 인자가 필요하거나 책임이 아예 다른 일을 하는 메소드도 많기 때문에 그런 메소드는
2. 새로운 객체를 생성해 역할.책임을 분리한다.
대충 이 정도의 리팩토링만 해줘도 제법 테스트할만하게 된다.
리팩토링에는 여러 기법이 있는데, 개인적으로 마틴파울러의 리팩토링 이란 책을 추천하고 싶다.
그리고 IDE 는 인텔리J를 추천하고 싶다. 이클립스 때 많이 사용하지 않던 리팩토링 기능이 인텔리J에서는 정말 자연스럽고 부드럽고 빠르고 정확하다.
아무튼, 위와같은 리팩토링 과정을 거치고나서, 테스트를 하려고 하면,
다른 여러 객체들과 연관되어 있다.
이때. 나는 연관되어 있는 다른 객체는 (임의로) 잘 작동한다고 가정하고 내가 테스트하려는 비즈니스 로직이 잘작동하는지만 확인하고 싶다..
바로 이때!! 필요한 것이 Mocking(가짜객체) 이고, 이 Mocking Object를 직접 만들지 않고 쉽고 간편하고 강력하게
만들어주는 프레임웍이 바로 Mockito 이다.
쉽게 말해,
내가 테스트 하려는 객체는 A객체인데 A객체에서는 b, c, d 객체와 연관을 맺고 있다.
그런데 나는 A객체안에서 특정 for, if 로직이 잘작동하는지만 확인하고 싶고, 다른 b, c, d 객체와의 행동은 잘작동한다고 가정 하고 싶다.
그러면 b, c, d 객체를 작작동한다고 가정하는 임의의 Mock 객체를 만들면 되는데, 이것을 Mockito 가 해준다는 말이다.
요즘은 거의 대부분 스프링 프레임웍을 이용하여 프로젝트를 진행한다.
스프링 프레임웍의 근간은 DI 이다.
다른 객체를 인터페이스 타입으로 의존성 주입을 받아서 많이 사용하는데 이때 의존성 주입을 받은 다른 객체들을 Mocking 하고 내가 테스트하고 싶은 객체에 집중하고 싶을 때. Mockito를 이용한 테스트를 한다.
.