이전 시간에 DB관련 테스트 작성하는 법을 다루어 봤는데, 이번 시간에는 Webflux handler 테스트 코드를 한번 작성해보려고 한다. 이전까지는 service 단까지만 테스트를 모듈별로 작성하였지만, 핸들러로 인입하여 한번에 모든 로직을 돌려보는 테스트는 직접 넣어보지 않았던 것 같다.(사실 핸들러, 컨트롤러 테스트가 이것저것 설정해야할 것들이 많아서..) 간단히 바로 예제를 다루어본다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 @Configuration public class RouteConfig { @Bean public RouterFunction routeFunction(TestHandler t..

이번 포스팅은 @RequestParam과 @ModelAttribute의 차이점에 대해 다루어볼 것이다. 이번에 다루어볼 내용은 특정 유저관련 컨트롤러 코드를 작성하여 살펴볼 것이다. 작업환경은 MacOS+intelliJ로 구성하였다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 @Slf4j @RestController @RequestMapping("/user") public class UserController { @GetMapping("/insert") public Object insertUser(@ModelAttribute("f..

작성하려는 코드가 있다면 항상 먼저 어떻게 그 코드를 테스트할지 고민해야한다. 코드를 작성한 후에 어떻게 테스트할지 고민하기보다 작성할 코드를 묘사하는 테스트를 설계해야 한다. 이것이 테스트 주도 개발(TDD, Test Driven Development)에 기반을 둔 단위 테스트 전략의 핵심이다. TDD에서 단위 테스트를 시스템의 모양을 잡고 통제하는 도구로 활용해야 한다. 단위 테스트는 종종 잘 선별한 후 한쪽에 치워 놓고 나중에 반영하려는 코드가 될 수 있는데, 단위 테스트는 소프트웨어를 어떻게 만들어야 할지에 관한 잘 훈련된 사이클의 핵심적인 부분이다. 따라서 TDD를 채택하면 소프트웨어 설계는 달라지고, 아마 훨씬 더 좋은 설계의 코드가 될 것이다. TDD의 주된 이익 단위 테스트를 사후에 작성하..

단위 테스트, 혹은 여느 테스트 코드를 작성하는 일은 상당한 투자와 비용이 드는 작업이다. 하지만 테스트는 프로덕 코드의 결함을 최소화하고 리팩토링으로 프로덕 시스템을 깔끔하게 유지시켜준다. 그렇지만 역시 지속적인 비용을 의미하는 것은 부정할 수 없다. 시스템이 변경됨에 따라 테스트 코드도 다시 들여다보아야한다. 때때로 변경 사항들을 생겨나고 그 결과로 수많은 테스트 케이스가 깨져 테스트 코드를 수정해야 한다. 그렇다면 만약 테스크 코드가 굉장히 복잡하고 지저분하다면 어떻게 될까? 새로운 변경사항이 생겨날 때마다 테스트 코드를 수정하는 일은 더욱 더 힘든 일이 될 것이다. 그래서 이번 포스팅에서는 테스트 코드를 리팩토링하여 유지보수가 쉬운 테스트 코드를 만드는 것을 간단하게 소개할 것이다. 이번 포스팅의..

이번 포스팅에서는 목(Mock) 객체를 사용하여 테스트하기 힘든, 혹은 외부환경과 의존성을 끊는 테스트를 하기 위한 방법을 간단하게 다루어 볼 것이다. 여기서 다루는 목(Mock)객체는 정말 단순한 수준의 예제이다. 결과적으로 이번 포스팅의 목적은 목객체는 무엇이고 왜 사용하는 지에 대한 내용이 될 것 같다. 지금 진행할 예제는 크게 코드 내용 자체를 알필요?는 없을 것 같다. 이 말은 우리가 개발하며 테스트를 작성할 때, 코드의 내용을 몰라도 된다는 말이 아니다. 테스트 작성은 당연히 코드의 내용을 빠삭히 알고 작성해야 하는 테스크이기 때문이다. 필자가 말하는 "알 필요는 없다"라는 것은 이번 포스팅은 독자들과 같이 애플리케이션을 개발하며 테스트를 작성하는 포스팅이 아니고 어느 순간에 목객체를 사용해야..

우리가 직접 작성한 코드라고 하더라도 단순히 메서드, 클래스 코드를 보면서 숨어 있는 버그를 찾아내는 것은 거의 불가능하다. 물론 코드를 살펴보는 것도 하나의 버그를 찾아내는 행위이긴 하다. 하지만 효율적인 단위 테스트를 통해 숨어있는 버그를 찾아내는 것이 훨씬 더 효율적인 방안일 듯하다. 그렇다면 테스트를 수행하는 것 만큼 중요한 것은 무엇일까? 아니, 올바르고 더 효율적인 테스트를 수행하기 위해 받침이 되는 행위가 무엇일까? 바로 테스트 케이스! 무엇을 테스트 해야할까를 고민하는 것은 아주 중요하고 여기서 그치는 것이 아니라 정말 중요한 테스트 케이스를 찾아 테스트에 적용해야한다. Right-BICEP는 우리에게 무엇을 테스트할지에 대해 쉽게 선별하게 한다. Right : 결과가 올바른가? B : 경..