전체 글

프롤로그 인간세상에 존재하는 다양한 언어로 인한 혼란은 고스란히 컴퓨터 세상으로 옮겨 갔다. 처음에 컴퓨터를 서양에서 만들었으니 그들의 언어와 문자만 고려했다. 우리와 같이 독자적인 언어와 문자를 사용하는 민족에게는 영어로 자료를 작성하고 보관하는 일이 사실상 불가능한 일이었다. 우여곡절 끝에 ASCII code라고 하는 서양의 문자를 정의하기 위한 문자 집합을 정의하듯 다양하고 고유한 문자를 정의하기 위한 문자 집합이 정의되었다. 세상의 모든 문자를 표현하고자 하는 취지의 유니코드만 존재하면 참 좋겠는데 우여곡절을 거치는 동안 다양한 문자 집합이 탄생하게 되었고 charset encoding 혼란의 근본적인 원인이 되었다. client - server에 데이터 전송을 전제로 구축되는 Web system..

프롤로그 성능 테스트는 사용자에게 전달될 시스템을 완성해가는 마자막 단계에서 성능 요구사항을 충족했는지 목표했던 평균 응답시간이 나오는지 해당 시스템이 몇 명의 동접자와 부하에서 오류를 내는 시점(임계점)에 도달하는지를 증명해 보여야 할 때 주로 사용된다. 개발자들은 보통 H/W나 OS, WAS 같은 인프라 요소 탓을 하는데 필자가 경험 해보면 문제는 대부분 비즈니스 로직에 있었고 때때로 DB 혹은 DB 연결객체 pooling 설정 부족으로 인해 쉽게 임계점에 도달하는 경우를 많이 봤다. 필자는 비즈니스 로직이 포함된 웹 어플리케이션의 테스트 보다는 현재 만들고 있는 Web, WAS 시스템의 성능적인 문제를 검증할 목적으로 성능 테스트를 바라보고 있다. 이유야 어찌 했던 웹 어플리케이션을 하나 정해놓고 ..

서론 가을에 제품(WEB, WAS) 출시를 앞두고 정식 메뉴얼을 준비중에 있다. 그동안 alpha test를 위해 컨플루언스에 임시 메뉴얼을 작성해놓고 이를 워드로 Export하여 테스터에게 전달했는데 컨플루언스가 만들어내는 워드가 영 마음에 들지않았다. 그래서 꼭 export하고 다시 디자인을 조정해야 했는데 그 양이 많아 질 수록 그 작업시간이 점점 늘어났다. 추가 변경되는 소프트웨어 제품의 특성상 메뉴얼의 현행화는 또 다른 업무 과중과 소프트웨어 품질에 영향을 미치는 요소다. 대책이 필요했다. 온라인으로 메뉴얼을 제공하고 필요에 따라 문서 파일로 전달할 수 있는 방안이 필요했다. 우리 CTO와 이 문제를 논의하던 중에 python 개발자들이 즐겨 쓰는 문서 자동화 솔루션(Open source)인 s..

프롤로그 필자는 요즘 java web application server를 만들고 있다. 그렇다 톰켓 같은거... 베타 버전을 배포해서 몇 몇 사용자로 부터 요구사항이 들어왔다. jps 명령으로 확인해봐도 되지만 JRE 만 깔려 있어 jps를 쓸수 없는 경우, 실행된지 모르고 또 실행한 경우가 있다는거다. 서버 프로세스의 실행을 감지하여 만약 같은 서버가 동작 중이면 실행한 서비스를 중단 시킬수 있냐는 것이다. 이번 글은 해당 요구사항을 해결하기 위한 필수 요소인 현재 시스템내에 실행 중인 VM 리스트를 구하는 방법에 대해 다루려 한다. 본론 참조 필자가 프로그램 코드에서 사용한 라이브러리는 JDK를 통해 배포되는 라이브러리로 알고 있다. 그래서 JRE만 설치되었거나 classpath에 문제가 있는경우 프..

간단한 팁 이니까 서론은 건너 뛰겠다. 인텔리제이를 사용하다 보면 여러 프로젝트를 열 일이 생기는데 여러 윈도우가 개별적으로 열리는 것이 필자는 그리 탐탁지 않다. 이를 해결할 방법이 없을까 하다. 우연치 않게 찾은 방법이다. 인텔리제이가 뭔 기능을 제공하는 것이 아니고 맥 시스템에 설정을 바꾸면 된다. 시스템 설정 > 일반 > 문서를 열 때 탭에서 열기 : 항상 참고 문서 https://youtrack.jetbrains.com/issue/IDEA-255898?_ga=2.138937463.574689316.1641886061-1061107801.1641533639

프롤로그 이번 글은 다국어 리소스가 포함되어 있는 프로젝트에서 다국어 문자열을 대상으로 하는 테스트가 필요한 경우에 대한 이야기다. 이런 상황에서 단정문을 작성하는 개발자는 혼란을 경험하게 된다. @Test void testGetMessage() { assertEquals("이 클래스 [{0}]는 생성할 수 없습니다." , Global.getMessage(Global.CANNOT_BE_CREATED, "CTest")); } 위와 같은 테스트가 내 한글 윈도우10에서는 잘 돌아 갔었는데 CI 서버로 올라가 빌드를 하면 위 테스트의 단정 메서드는 fail을 뱉어낼 것이다. 우리 빌드 서버 역할을 하는 github는 영문 OS를 제공하기 때문이다. 필자가 격은 이 상황을 해결해 나간 과정을 정리하려 한다. 참..

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

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

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

프롤로그 지난 글에서 JAVA의 Throwable 그리고 Exception 클래스들의 계층 관계를 살펴보고 Unchecked, Checked 가 어떻게 구별되는지 왜 구별을 해야 하는지 생각해보는 기회를 갖었다. 이번 글에서는 이렇게 발생한 예외를 어떻게 다루어야 할지를 정리해보도록 하겠다. 일전에 C#의 예외처리에 대한 글을 쓸 때도 언급을 했는데 필자는 예외처리를 위해 try... catch를 남발하는 것을 매우 경계한다. 이는 가독성을 떨어뜨리고 전체적인 로직의 흐름에 방해 요소로 작용하여 유지 보수성을 떨어뜨려 결국 프로그램 품질에 까지 영향을 주는 요소로 작용한다. 프로그램 매니저 역할을 하던 시절에는 단위 모듈 개발자들에게 "그 어디에서도 try... catch를 쓰지 마세요."라고 하고 메인..

프롤로그 필자가 프로그래밍을 하면서 가장 신경 쓰는 부분이 예외처리다. C# 관련 글에도 예외 처리를 쓴 적이 있는데 완수를 못해서 늘 마음에 걸린다. 지금은 어찌하다 보니 현 개발 프로젝트가 JAVA가 되는 바람에 상당기간 동안 JAVA를 주력 언어로 써야 한다. 그래서 C#은 나중으로 미루고 JAVA의 예외 처리를 먼저 정리해보려 한다. 이번 글에서는 JAVA의 예외 처리 Class들에 대해서 고민해보는 시간을 먼저 갖으려 한다. Throwable, Exception, Error 위 그림은 JAVA의 예외처리 Class들의 상속체계이다. 가장 super 위치에 Throwable 이 자리 잡고 (있다. 그렇다 모든 예외 처리 Class의 super base이다. 모든 예외나 에러가 이 Class로부터 ..

프롤로그 이전 글에서 교착상태가 무엇인지 이를 재현해보고 교착상태의 thread를 검출해봤다. 이번글은 명시적인 Lock을 이용하여 교착상태에 빠진 thread를 탈출시키는 방법을 제시 해보려 한다. 명시적 Lock의 사용 JAVA의 명시적인 Lock은 표준 JDK 에서 총 3가지로 제공된다. ReentrantLock, ReentrantReadWirteLock, 그리고 일전에 다루었던 StampedLock이다. 명시적인 Lock은 Java의 Object에 숨어있는 암묵적인 Lock보다 그 야말로 명확하다. 블록이 아닌 lock / unlock의 명시적인 호출로 Lock을 건다. 그렇기에 위험하기도 하다. private ReentrantLock lock = new ReentrantLock(); // 중략 ..