BeeKim's log BeeKim's log

자바 기반으로 애플리케이션을 작성 할 때 좋은 점은 셀 수 없을 정도의 다양한 프레임워크, 라이브러리, 도구등의 도움을 받을 수 있다는 점입니다. 현시점을 기준으로 다른 어떤 개발 언어도 자바만큼 많은 지원 도구들을 가지고 있지 않을 겁니다. 사실 너무 많아서 골라 쓰기도 쉽지 않을 정도죠… 그렇게 많은 프레임워크 중에서도 제가 가장 좋아하는 프레임워크가 있는데 바로 jUnit 테스트 프레임워크입니다. 존경해 마지 않는 켄트 백 횽님, 에릭 감마 횽님(두 분 모두 61년생)의 역작이면서 제가 본 가장 직관적이고 우아한 프레임워크 중에 하나 이기도 합니다. 게다가 배우기도 쉬어서 jUnit만 놓고 본다면 배워서 사용하는 데 하루도 걸리지 않을 겁니다. 하지만 보통 아무리 좋은 프레임워크라도 그 자체만으로 ..

데이터베이스와 관련된 기능의 검증을 위해 단위 테스트를 작성할 때 DbUnit을 사용하면 많은 도움을 얻을 수 있다. DbUnit을 통해 테스트 메소드 실행 전에 픽스처를 데이터베이스에 입력하고 테스트가 종료되면 삭제하는 일을 아주 편하게 할 수 있기 때문이다. 이를 통해, 테스트 메소드의 독립적인 수행을 보장하고, 테스트 데이터베이스를 항상 깨끗한 상태로 유지할 수 있다. 하지만 가끔 문제가 생기는 경우가 있는데 동일한 테이블에 넣어야 하는 테스트 데이터의 크기가 다른 경우이다. 보통 다음과 같은 경우가 되겠다. 이 경우 테스트케이스를 구동하면 column-3, column-4의 값이 누락되어 입력이 안된다. 상위에 있는 데이터셋(dataset)에 컬럼이 두 개만 설정되어 있기 때문이다. DBUnit은..

소프트웨어의 품질은 크게 두 가지 측면으로 나눠 볼 수 있습니다. 외적인 품질(External Quality)과 내적인 품질(Internal Quality)입니다. 외적인 품질은 사용자 측면에서의 품질을 말합니다. 사용자가 원하는 기능이 모두 제공되는지, 괜찮은 UX를 제공하는지 여부와 가용성, 속도 등이 보장되는지가 이 범주에 속합니다. 이런 외적인 품질은 보통 소프트웨어의 성공과 생존 여부를 결정하는 아주 중요한 요인이 됩니다. 사용자에게 외면 받는 소프트웨어는 존재의 의미가 없기 때문입니다. 내적인 품질은 개발과 유지보수를 얼마나 잘 할 수 있는가와 관련됩니다. 비즈니스에 맞는 적절한 아키텍처가 선택되고 잘 설계, 구현 되었는지 여부로 측정할 수 있습니다. 결국은 개발자가 느끼는 품질이라고 보면 될..

제가 처음으로 회사에 취직해서 개발을 시작할 무렵은 EJB의 시대였습니다. EJB 스펙을 구현한 웹로직, 웹스피어, Jboss같은 웹 애플리케이션 서버가 웹앱 시장을 장악하고 있었고 EJB 코딩이가능한 자바 개발자를 찾는 구인 광고가 넘쳐났습니다. 처음 사회에 나온 어리버리한 신입사원이었던 저는 EJB아니면 엔터프라이즈웹 웨플리케이션을 작성할 수 없는 줄 알았습니다. 그렇게 몇 년을 세션빈, 엔티티 빈에 묻혀 살면서 수많은 EJB 코드를 작성했습니다. 사실 EJB 스펙에 맞게만 코딩을 하면 트랜젹션 관리, 데이터소스 관리 같은 직접 구현하기 어려운 기능을 알아서 해주는 건 상당히 매력적이긴 했습니다. 하지만 그 시절은 저에게 개발하기가 무척 어려웠던 시절로 기억됩니다. 잘 알지도 못하는 DD(Deploy..

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

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

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

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