BeeKim's log BeeKim's log

데이터베이스에 대한 단위 테스트를 작성하고 실행하기 위한 전략으로 우리는 보통 로컬 컴퓨터에 테스트용 데이터베이스를 구축하고 테스트를 수행합니다. 개인 PC에서 테스트가 성공적으로 수행되면 SVN, CVS같은 소스형상관리 서버에 커밋을 하게 되고, 이를 CI(Continuous Integration) 도구가 통합하게 됩니다. CI도 통합 테스트를 수행하기 위해 테스트 데이터베이스가 필요한데 이럴 때는 공용 테스트 데이터베이스를 따로 구축해서 사용하고 있습니다. 로컬 데이터베이스는 개발자가 마음대로 변경할 수 있기 때문에 구현하고 있는 기능에서 필요한 데이터베이스 변경 사항을 바로 반영해 테스트를 수행하며, 테스트가 온전히 수행되면 변경내역을 공용 데이터베이스에 반영합니다. (직접 하거나 혹은 DBA를 통..

메이븐 사용시 간혹 소스 파일에 대한 인코딩이 POM(Project Object Model)파일에 정의된 것과 다르게 저장될 경우 컴파일오류가 발생할 수 있다. 그런데 컴파일 에러 내용이 좀 생뚱 맞아 원인을 찾지 못하고 버벅 거릴 수 있어 팁을 남겨 본다. 예를 들어 POM.xml 파일에 자바 소스 파일과 거타 리소스 파일에 대한 인코딩이 다음과 같이 각각 euc-kr 과 UTF-8로 설정되어 있다고 가정하자. ...어쩌구 저쩌구.. org.apache.maven.plugins maven-resources-plugin 2.4.1 UTF-8 org.apache.maven.plugins maven-compiler-plugin 2.3.2 1.5 1.5 euc-kr ...어절씨구 저절씨구.. 위와 같은 경우 ..

자전거 창피한 이야기를 하나 고백해야겠다. 뭐냐 하면 나는 자전거 타는 법을 한 번에 배우지 못했다는 것이다. 나는 또래 친구들 보다 상당히 늦게 자전거를 배웠는데, 그 때가 중학교 1학년 때쯤인 것 같다. 그 때는 벌써 자전거를 타고 학교에 등교 하는 친구들이 많이 있었는데도 나는 자전거를 탈 줄 모르는 상태였다. 어느날 친구들과 이야기 중에 화제가 자전거로 옮겨졌고 내가 자전거를 탈 줄 모른다는 사실을 안 친구들은 날신기하게 쳐다 봤다. 그리고 한 친구가 주말에 자전거 타는 법을 알려주겠다고 제안했는데 그 당시 어떻게든 자전거를 배워야 한다고 생각하고 있던 난 그 기회를 놓칠 수가 없었다. (이미지출처) 그때부터 두려움 반 설렘 반으로 주말을 기다리며 난 머리 속으로 수 없이 자전거 타는 법을 연습했..

1999년 말, 런던에 Archway 역 근처의 라운드어바웃에서 이야기가 시작된다. 어느 저녁 런던 소프트웨어 아키텍처 그룹의 몇몇 멤버들이 그 당시에 주요 소프트웨어 이슈에 대한 이야기를 나누기 위해 모여 들었다. 이야기는 애자일 소프트웨어 개발에 대한 경험을 나누는 방향으로 옮겨갔고, 나는 테스트를 작성하는 것이 우리 코드에 끼치는 영향에 대해 이야기 했다. 사실 이 시점은 첫 번째 익스트림프로그래밍 책이 출판되기도 전이었고, 우리 같은 팀들은 무엇을 가져야 좋은 테스트인지를 포함한 - 어떻게 하면 TDD를 제대로 할 수 있는지에 대해 아직 탐험(연구) 중이었다. 특히, 나는 테스트를 용이하게 하려다 보니 객체에 “”getter”메소드를 자꾸 추가하게 되는 경향에 대해 이야기를 했는데, 사실 이런 행..

IBM Developerworks를 보다가 mysql 최적화에 관련된 흥미 있는 내용이 있어 로그로 남겨본다. 데이터베이스를사용해서 애플리케이션을 개발할 때, 성능 이슈를 해결하기 위해 느린 쿼리를 찾아내야 하는 일이 종종 있는데 해당 기사에서는 Mysql을 데이터베이스로 사용할 때 느린 쿼리를 잡아내는 방법에 대한 소개가 있어 좀더 상세히 적어본다. Mysql에서는 실행 시간이 오래 걸리는 쿼리를 잡아내게 위해서는 먼저, 설정파일에 로그 파일을 기록할 위치와, 몇 초 이상 걸리는 쿼리를잡아낼 건지를 설정해야 한다. 설정하는 방법에는 두 가지 방법이 있는데 먼저 이야기할 것은 config파일에설정하는 방법이다. 보통 리눅스에 mysql을 설치할 경우설정 파일(my.출)이 /etc/mysql/my.cnf에..

오랜 기간 동안 SI 프로젝트를 뛰면서 많은 프로젝트를 경험했습니다. 그 중 많은 프로젝트가 어렵고 힘든 상황이었지만 성공했습니다. 물론 때로는 비교적 편하게 일하면서도 성공한 프로젝트도 있습니다. 프로젝트의 상황이 어떠했던 간에 성공한 프로젝트는 좋은 기억과 긍정적인 경험을 줍니다. (이미지출처) 제가 경험했던 프로젝트 중에 당연히 실패한 프로젝트도 있습니다. 대다수가 정치적인 성공으로 포장되긴 했지만요. 프로젝트에 참여했던 구성원으로써 저는 프로젝트가 분명히 실패했음을 압니다. 그리고 그런 모든 실패한 프로젝트는 한결같이 어렵고 힘든 기억으로 점철됩니다. 그리고 돌이켜보면 성공한 프로젝트는 프로젝트를 성공적으로 이끌 수 있었던 이유가 분명히 존재합니다. 프로젝트의 성공과 실패를 불러오는 차이가 무엇일..

어떤 메소드나 프로시져를 테스트한다고 가정해 보겠습니다. 테스트 하려는 메소드는 여러 개의 파라미터를 갖고 각 파라미터는 또 여러 종류의 값을 취할 수 있습니다. 예를 들어 메소드가 3개의 파라미터를 갖고 각 파라미터는 10가지 경우를 갖는 다면, 파라미터가 조합될 수 있는 경우의 수는 10 X 10 X 10 이 되므로 총 1,000가지 경우가 됩니다. (이미지출처) 이제 테스트를 작성하려고 합니다. 1,000가지의 경우에 대한 테스트 코드를 모두 작성해야 할까요? 아마도 다들 고개를 저으실 겁니다. 모든 경우를 다 테스트하려 한다면 큰 비용이 들기 때문입니다. 또한, 비용 대비 효과도 그닥 장담할 수 없습니다. 이런 다양한 조합을 테스트할 수 있는 좋은 방법이 있을까요? 먼저 소개해 드릴 방법은 “모든..

테스트를 작성할 때 코드를 어떻게 작성해야 할지 고민되는 시점이 있는데 바로 작성한 테스트가 잘 수행되었는지 검증(Verification)하는 부분을 작성할 때입니다. 검증할 데이터가많거나 복잡한 경우 Assert문으로 검증하는 게 어렵게 느껴지기 때문입니다. 예를 들어, 검증할 객체가 리스트 안에 여러 개 들어 있다거나, 리스트 안에 들어있긴 한데 몇 번째 있는지는 모른다거나, 아니면 들어 있는 순서가 테스트 수행할 때마다 바뀐다던가 하는 경우에 특히 그렇습니다. 이럴 경우, 테스트를 검증하기 위해 루프나 조건문을 사용하고자 하는유혹을 느끼게 됩니다. 뭐 딱히 안될 것도 없구요. 다음은 그렇게 해서 등장하는 검증 로직입니다. 저도 이전에 이런 식으로 테스틀 작성하곤 했습니다. public void te..