2021/02

프롤로그 요즘 IDE 또는 그 확장 솔루션들 예를들어 SonarLint 등이 아주 아주 성능이 좋아져서 중복된 코드나 복잡도가 높은 코드를 발견하면 잔소리를 늘어 놓는다. 사람이 하는 잔소리라면 한번 듣고 넘어가겠지만 계속 노란줄로 너 이거 “계속 안고칠꺼야?” 하고 경고를 한다. 테스트를 작성하다 보면 흐름은 거의 비슷하고 데이터 만 바뀌고 여기에 따라서 단정문도 살짝 바뀌는 수준의 테스트 메서드를 여러개 작성하게 된다. 이 경우 요즘 정적 분석기는 이런 중복도 잡아 준다. 뭐 정적 분석기가 잔소리를 하던 말던 제품 코드 뿐만 아니라 테스트 코드도 중복되어 좋을 것이 없다. 오늘은 이 문제를 해결하기 위한 방법을 하나 소개한다. Parameterized test 궂이 우리 말로 번역하자면 인자화 테스트..

프롤로그 현재 필자의 개발 프로젝트에서 사용하고 있는 빌드 시스템이 그런것인지 원래 JUnit이 그런것인지 모르겠으나 테스트 메서드가 여러개 존재하는 경우에 테스트 에이전트가 이를 동시에 실행하는 현상이 발생 했다. 예를 들어 동일한 TCP 포트를 사용하는 테스트 메서드가 존재하는 경우 이미 열려있는 포트로 인해 다음과 같은 예외가 발생한다. java.net.BindException: Address already in use: bind 물론 테스트 메서드마다 각자 다른 포트를 사용하게끔 하여 문제를 원천적으로 막으면 된다. 그러나 현실을 그렇지 못하다. 보통 이런 포트들은 서버 리스닝 포트고 테스트 및 단정을 하기위해서 클라이언트 모듈로 접속을 해봐야 하는데 각기 다른 포트로 클라이언트-서버 짝을 맞추어..

프롤로그 테스트를 작성하고 관리하던 중 특정 PC에서만 동작하는 테스트가 발생 했다. 원칙적으로는 모든 환경에서 테스트가 가능해야 하지만 진짜 그렇게 하려면 엄청난 노력을 해야 한다. 예를 들어 JNDI로 DB pool을 테스트 하기 위해 리얼 DB를 접속해서 쿼리를 해보는거 까지 진행되는 테스트 시나리오의 테스트 코드가 있다고 가정 했을때 이 테스트를 내 개발환경이 아닌 다른 머신에서도 동작하게 하기 위해서는 DBMS가 모두 접근 할 수 있는 위치에 있거나 테스트 수행전에 관련 설치를 해야 하는데 현실적으로 쉽지 않다. 특히나 현재 우리팀이 사용하고 있는 GitHub Actions를 통한 빌드를 하는 경우 더더욱 힘든 일이다. 본론 트레이드 오프(현실과의 타협) 이런 테스트 코드를 남겨둔체 소스를 서버..