[Play] 테스트 로그도 영…

이런 테스트 코드 실행했을 때 아래와 같은 에러가 났다면 대체 13줄이 문제라는거야 14줄이 문제라는거야…

도통 알수가 없어… 왜 라인수를 알갈쳐주는거야… 장난 치는거야 지금? 이게 어디서 났는지 찾아봐라? 머 그런거야? 지금 나랑 한번 해보자는거지? 재미없으니까 테스트 assert  실패한곳 라인수 찍어놔.. 당장 찍어 내라고!!!

OSIV 패턴 사용시 SQL 누수 현상에 대한 대처 방안

OSIV 패턴을 안티 패턴으로 보는 시각도 있다. 이해한다. OSIV 필터나 인터셉터를 사용하면 개발할 때 편하지만, 뷰 랜더링 시점에 예측하지 못한 쿼리가 발생해서 시스템 성능에 영향을 줄 수 있다. 그래서 확인해봐야 하는데.. 문제는 테스트할 때 OSIV 필터 적용으로 발생하는 추가적인 SQL까지 잡아낼 수 있느냐가 관건이다.

결론부터 말하자면, 그렇게 새어나가는 SQL을 모두 잡을 수 있다.

쉽다. 서블릿 컨테이너에 무조건 올려서 해당 URL을 모두 브라우저 주소창에 입력하고, 매번 콘솔로 가서 찍힌 쿼리 목록을 수집하면 된다. 쉬운데 피곤하다. 그래서 자동화된 테스트가 필요하다.

토비의 스프링 3을 잘 읽은 사람이라면 손쉽게 이 불편함을 해결하면서 새어나가는 SQL을 잡아낼 수 있다.

지금은 업무 중이라 길게 못 쓰겠다. @_@;; Adios~

 

ps: 참 애매하다. 내가 업무 중에 알아낸 기술적인 내용을 블로깅 해도 되는 것일까 안되는 것일까. 잘 모르겠다. 업무 시간에 내가 알아낸 사실들은 전부 회사의 자산으로 봐야하기 때문에.. 내가 업무중에 알아낸 내용을 공개하면 처벌을 받을 수도 있겠다. 그런데.. 내가 업무중에 알아낸 내용은 내가 이 회사에 다니기 전부터 공부해 왔던 지식들이나 업무중이 아닐 때 머리속으로 생각한 내용 때문이기도 하다. 그리고.. 내가 업무 중일 때 알아낸 게 사실은 업무 중이 아닐 때 알아낸 것일 수도 있다. 스터디에 나가서 상담을 했다거나, 다른 회사에 다니는 사람과 전화 통화를 하다가 알아 냈다거나.. 그런거는 블로깅을 해도 되는 것일까?

모르겠다. 한가지 분명한건 회사가 알려준게 아니라 내가 알아낸 거다.

그러니까.. 내가 업무 중이 아닐 때 알아냈다고 우기면 그만 아닌가? 내 머릿속에 DRM이나 감시용 프로세스를 달아 놓은게 아니라면 어떻게 알겠어..

Why OSAF 1. 테스트 코드를 익힐 수 있습니다.

OSAF를 공개한지 한 달이 아직 안 됐습니다. 10월 23일에 공개했었죠. 지금까지 약 200에 가까운 다운로드를 기록하고 있지만, 전혀… 아무런… 반응이 없다는 것에는 가히 놀라울 뿐입니다. 그냥 제가 쓴 글의 댓글 몇 개 정도 뿐의 관심이 저에게 한 편으로는 아쉬움으로 또 다른 한 편으로는 오기로 다가옵니다.

완전 최첨단 프레임워크인 OSAF에 왜 이렇게 관심이 없을까. 고민을 많이 했습니다. 어렵나? 메이븐 떄문인가? 그거 없어도 되는데. 문서가 부족하긴 부족하고. 그래도 어떻게 이렇게 조용할 수가 있지. 홈피 디자인이 좀 구리긴 한데.. 그거 때문인가? ㅋ. OSAF 발음이 너무 어려운가? 별에 별 생각을 많이 했습니다. 당연히 기운도 빠집니다. OSAF를 공개한 건 어쩌면 OSAF에게 못씁짓을 한 건 아닌지 말이죠.(Max님의 ‘어디가서 밥은 먹고 다녀야 할텐데..’ 라는 댓글이 생각납니다.)

긍정적으로 생각하기로 했습니다. 언젠가는 빛을 보겠지. 열심히 계속 가꾸다 보면 언젠간 알아주겠지. 하고 말이죠. 그래서 OSAF가 여러분에게 어떤 도움을 줄 수 있을지 생각하고 알려드리기로 했습니다. 그 중 첫 번째가 바로 테스트 코드입니다.

OSAF의 테스트 커버리지는 60%가 조금 넘습니다. (앞으로 차차 올릴 예정입니다.) 60%의 테스트 커버리지는 전부 OSAF 개발팀에서 직접 작성한 테스트 코드입니다. 어딘가에서 배껴온 코드가 절대로 아닙니다. 테스트는 초기에 JUnit과 EasyMock을 사용해서 작성 했었습니다. 물론 스프링 테스트 기능도 사용하고 있죠. 배포 직전에는 EasyMock을 Mockito로 교체하여 비슷한 테스트를 보다 깔끔하고 직관적이며 적은 수의 코드로 대체할 수 있었습니다. DBUnit을 확장하여 OSAF가 제공하는 테스트 케이스를 이용하면 DAO 테스트가 매우 간편해질 것 입니다.

이렇게 좋은데… 한 번 들여다 보고 뭐라고 해주시지 않으시겠어요? 좋다. 잘했다. 고맙다. 이런거 말구요. 이 부분의 테스트는 이해가 안 된다. 테스트가 조금 이상하다. 이 부분의 테스트는 왜 안했냐. 어려워서 그런거냐? 이 부분의 테스트는 이렇게 고치는게 좋치 않겠냐? 이런.. 반응이 제가 가장 좋아하는 반응이자 OSAF에게 거름을 주는 방법입니다.

소스 코드는 굳이 다운 받지 않아도(장기적으론 받아 두시면 좋겠지만..)

http://www.opensprout.org:9060/browse/OSAF/osaf/trunk

위 링크로 가시면 웹에서 직접 볼 수 있습니다. 소스 코드나 OSAF 와 관련하여 문제나 제안하고 싶은 것이 있다면 주저하지 마시고 이슈를 등록해 주세요.

http://www.opensprout.org/jira/secure/Dashboard.jspa