Junit.. 단위 테스트.. 처음 접하게 된건 비X교육센터를 다니면서 어설프게 사용을 해봤고,

첫 직장에서는 그 어설픔으로 java, 클래스 파일만 쓸데없이 늘려나갔고 -_-

현, 두번째 직장에서는 나름 단위 테스트 답게 사용하고 있다. 물론 100% 활용이라고 까진 못말하지만 말이다...T^T


지금 직장에서 배우면서 가장 많이 들었던 말은.. 남들이 내 코드를 읽어내려갈때 쉽게 읽힐수 있는 코드를 짜라는식의 말을 많이 들었다.

변수, 메서드의 이름만으로 이해할 수 있는..


거짓말은 잘해봤어도 글짓기는 잘 못했었는데.. 이름짓기 참 힘들더라능~ -_- 쿨럭;;


여튼; 나름 junit을 이용해서 테스트 주도 개발!을 하고 있고!! 많이 익숙해져있는 지금..!

다른 유명하신분들 블로그 기웃거리다 보니 Hamcrest 라는게 TestCase 코드에 보이더라..


그 코드들.. 하나하나 조목조목 유심히 살펴보면 정말 직관적인것 처럼 보인다.

구글링 하다보니 이런 코드가 있던데.. 사용해본적이 없어서 맞는 문법인지는 모르겠다.

    @Test
    public void should_find_embedded_search_term_at_start() {
        List<Stakeholder> stakeholders  = stakeholderManager.findByName("Health");
        assertThat(stakeholders, hasItem(hasProperty("name",is("Health Associates"))));
    }

대충 내용은..

' health라는 stakeholder 리스트를 가져온다, 그 중 name이 Health Associates인 프로퍼티를 가지고 있는 객체가 있나? '

뭐 이런 테스트를 하는것 같다.


더 복잡한 케이스도 있었는데 직관적?.. 글세 눈에 안들어오더라;;


-_-;; 해보지 못해서 설명이 안되는것 같다...;;


이렇게 해봤다.. 좋은 개발자는 구글 검색도 잘한다던데....--;; 참 힘들게 테스트 케이스 하나 성공시켜봤다;


내 나름대로 해석은..

' person리스트 요소중에서 'name''minato0'인 property를 가지고 있는 person이 있느냐.. ' 였다.


확실히 Loop를 돌리지 않고 저런식으로 Collection 요소를 검색하는 방법, 은근 좋긴 하다.


걱정은 Hamcrest를 사용하면, 나 외에 다른 사람들이 테스트 코드를 봤을때 거부감이 생기진 않을지,

시간을 들여 공부, 적용, 적응 해볼만한건지.. 흠....

구현하다보면 설계했던거 보다 더 좋은 방법이 떠오르거나 또 그것으로 인해 생각이 복잡해지는 경우가 많습니다. 이럴때 조심해야 할게 있는데, 설계 변경 시도를 코드로써 풀어내려 하면 안된다는 것입니다.

실제로 전 기수 프로젝트 때 설계에 대한 부분을 중요시 생각 안하고 생각 나는대로 코드로써 풀어나갔었습니다. 막히는 부분도 많았고 점점 알수 없는 코드들로 변해갔습니다. 원하던 결과 값은 나왔으나 알수없는 계산식들...

지금 다시 그 코드를 보면 정말 무식하게 코딩했구나 라는 생각이 들고 또 느낀것도 많았는데, 일단은 설계했던 대로 구현해서 테스트를 통해 기능이 제대로 작동되는지를 우선시 하고, 그 이후에 보완하는식으로 하는게 가장 좋을꺼 같단 생각을 했습니다.

그래서 이번 프로젝트는 단위 테스트(Junit4.4)에 비중을 많이 두고서 진행하고 있고, 안정적이면서 최대한 빠르게 구현하고, 그 이후에 좀 더 나은 방법으로 보완해 나가면서 버전업을 할 계획입니다.

일단 Hibernate Tool을 사용하였고, GenerationSchemaExport를 통해 Model, Schema생성을 한번에 해결하였습니다.

src 폴더에 실질적인 구현 코드들이 만들어지고 있고, test/java와 test/resource에 테스트 코드와 테스트에 필요한 설정파일들을 배치하였습니다. 보시는대로 전체 모듈에 대해서 최대한 테스트를 통해 구현하고 있습니다.
 

비록 간단한 소스 코드이긴 하지만 이러한 작은 것들부터 테스트를 수행하고 빠진 부분이 없는지 확인합니다.

IBatis로 했다면 쿼리문에 대해 많이 신경썼을테고 오류도 쿼리문에 대해서 많이 나왔을테지만 Hibernate는 Mapping 문서에 설정된 연관 관계들과 쿼리 실행전, 후 필요한 설정들에 대해 신경을 써야 합니다. 

Dao와 마찬가지로 비지니스 로직단도 테스트를 수행하며, Controller까지 테스트를 완료하는것으로 한 모듈을 마치게 됩니다.

간단한 MultiActionController 테스트 입니다.
methodParameter 방식을 사용하지 않고 Url경로로써 바로 메서드를 호출 하는 방식을 택했습니다. (상황에 따라서는 methodParameter 방식도 사용하긴 합니다.)


Url 요청이 들어왔을시에 Url에 맞는 메서드가 호출되는지의 확인과 요청된 데이터가 제대로 넘어오는지 테스트합니다.


SimpleFormController도 마찬가지 입니다. (유효성 검사는 아직 진행 단계가 아니라서 제외되었습니다.)

폼 요청시에 필요한 데이터를 가져올수 있는지와 데이터를 전송했을때 데이터를 제대로 바인딩 하는지, 등록과 수정은 제대로 이루어 지는지 테스트를 합니다.
 
현재 모든 모듈들은 이러한 방식으로 테스트를 진행중에 있고 플랙스가 사용되는 부분은 Service단까지만 구현중에 있습니다.

예전에는 테스트 없이 model, dao, service, controller를 모두 구현한 뒤에 웹페이지를 띄워보고서 제대로 작동하는지 확인을 했었는데, (그러다가 결국 원점으로 돌아와 다시 수정을 하곤 했습니다.) 지금 생각해보면 정말 미련하게 개발하진 않았나 싶기도 하고 느낀것도 많았습니다. 항상 모든 프로그램은 실제 상황을 기준으로 모의 테스트를 하되,최하 밑단부터 시작해서 차근차근 구현해 나가야 할 것 같습니다.

'Project > B.M.S' 카테고리의 다른 글

Hibernate.  (0) 2012.03.05
ERD.  (0) 2012.03.05

+ Recent posts