테스트코드 작성 하시나요?

@K 말씀하신 단점이 없으면 테스트 코드 작성이 좋다는 말씀으로 보입니다. controller 에 대해서는 테스트 코드를 작성하지 않고 mocking 도 managed dependencies 에 대해 사용하지 않는다면 극복할 수 있는 문제 같습니다.

@K 의견 감사합니다. 저도 비슷한 경험을 하면서 힘겹게 UnitTest 에 경험을 쌓아왔습니다. 한마디로 정리하면, Framework (Spring) 에 의존된 대상을 테스트하게 되면 어려워 지는 케이스가 많았습니다. 특히, Controller 의 경우 SpringMVC 기반이라면 완전한 SpringFramework 에 의존된 테스트가 되어서 skip 을 하게 되거나, 주요 SpringMVC 의 annotation 을 학습하는 용도로 테스트 작성합니다. 예를들어, Path Parameter 를 처음 사용하는데, 정말 path value 가 controller 의 parameter 로 주입이 되는지를 검증하죠. 간단하게 저의 기준을 말씀드리면, 1. mocking 은 최소화 합니다. (리팩토링시 지옥을 경험함...) 2. 추상화된 데이터타입(domain, dto, vo 등)을 활용하게 됩니다. 3. Servie Layer 는 비지니스 흐름 + transaction 경계로만 활용하고 Test 는 Read Transaction 은 선택적, Write Transaction 쪽은 인수테스트 형태로 작성중입니다. 항상 내가 테스트 할려고하는게 Framework 에 의존되지 않게 하는게 중요했던것 같네요. 좀 더 구체적인 사례를 앞으로 글을 통해서 계속 공유 드릴 예정입니다.

@K 저도 개발 하다보면 가끔 말씀하신 비슷한 문제나 이런것까지 해야되나??싶은 경우도 많이 있는데요. 그래서 최근에는 단위 테스트는 줄이고 차라리 통합 테스트를 늘리는 방향으로 가고 있습니다. 아직 스타일을 바꾼지 얼마 안되서 실효성 확인은 잘 안됐지만 조금은 편해진 느낌입니다. 이후 유지보수건이 발생할때에나 실효성 확인이 될거 같아요.

@K 비즈니스 로직에 스프링에 대한 의존성을 없애고 pojo 클래스로만 작성. mocking 은 언제 하는가 하면 상태 값 검증 보다 동작 검증을 위해 사용 하는게 좋다고 생각 합니다. 스프링에서의 controller, service 은 단지 값을 전달하고 불러오기 위한 코드만 존재하는거죠

스프링 의존성을 최소화하려면 결국 각 클래스들을 인터페이스로 정의하고 테스트를 위한 스터빙이 필요해집니다. 결국 K님의 의견대로 테스트를 위해 비즈니스 로직이 더 복잡해지는 결과는 동일하게 나타나지 않을까요? 저도 K님과 동일한 의견이긴 하네요.

@K 사실 모킹을 최소하하는건 문제가 있습니다. 서비스 자체가 굉장히 단순한 트랜잭션마누요구한다면 가능하지만 대부분의 경우 그렇지 못하고, nosql기준으로 여러 db 컬렉션에 접근하게 될 가능성이 높죠. 추상화를 하더라도 모킹을 해야되는건 마찬가지겠죠? 그렇다고 단위테스트를 버리고 E2E 테스트를 하자니 네트워크 고려 및 테스트 db를 사용하는 과정에서 생기는 테스트 자체가 느려지는 상황도 올 수 있구요. 사실 프레임워크에 의존하냐 안하냐의 문제보단 내 코드 내의 모듈화를 어떻게 가져가는지가 더 중요해 보여요. 모듈화된 함수들을 테스트하는게 원래의 목표였으니까요. 사실 점점 테스트 코드가 정말 이득인가? 하는 의문이 많이듭니다. 좋은 글 감사해요

@이준식 전체 코드에 적용은 보통 e2e 테스트라 하고. unit test 라고 기능별로 테스트 코드를 작성해 놓습니다. 모든 경우에 유닛 테스트 코드를 작성한다는건 현실적으로 불가능하고, 단위 핵심 코어 기능에 테스트 코드를 넣어서 중요 코드를 보호하는 역활로 사용하기도 합니다. 프로그램의 사이즈가 커서 빌드할때 로딩할때 너무 오래 걸리는 경우, 테스트 코드로 개발해서 적용시켜 넣기더 하고요